The reproducer for another problem tripped an assertion failure:
$ nmcli con del act-conn
Connection 'act-conn' (...) successfully deleted.
$ nmcli con down another-conn
(process:94552): nm-CRITICAL **: 17:07:21.170: ((src/libnm-client-impl/nm-remote-connection.c:593)): assertion '<dropped>' failed
Connection 'another-conn' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)
$
What happens is that the second invocation, when resolving the
connection name into a NMRemoteConnection object, assumes an active
connection has a settings connection.
This assumption is likely to be wrong immediately after deleting a
connection was active, before giving the active connection enough time
to fully deactivate.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1317
It can be useful to choose a different "ipv6.addr-gen-mode". And it can be
useful to override the default for a set of profiles.
For example, in cloud or in a data center, stable-privacy might not be
the best choice. Add a mechanism to override the default via global defaults
in NetworkManager.conf:
# /etc/NetworkManager/conf.d/90-ipv6-addr-gen-mode-override.conf
[connection-90-ipv6-addr-gen-mode-override]
match-device=type:ethernet
ipv6.addr-gen-mode=0
"ipv6.addr-gen-mode" is a special property, because its default depends on
the component that configures the profile.
- when read from disk (keyfile and ifcfg-rh), a missing addr-gen-mode
key means to default to "eui64".
- when configured via D-Bus, a missing addr-gen-mode property means to
default to "stable-privacy".
- libnm's ip6-config::addr-gen-mode property defaults to
"stable-privacy".
- when some tool creates a profile, they either can explicitly
set the mode, or they get the default of the underlying mechanisms
above.
- nm-initrd-generator explicitly sets "eui64" for profiles it creates.
- nmcli doesn' explicitly set it, but inherits the default form
libnm's ip6-config::addr-gen-mode.
- when NM creates a auto-default-connection for ethernet ("Wired connection 1"),
it inherits the default from libnm's ip6-config::addr-gen-mode.
Global connection defaults only take effect when the per-profile
value is set to a special default/unset value. To account for the
different cases above, we add two such special values: "default" and
"default-or-eui64". That's something we didn't do before, but it seams
useful and easy to understand.
Also, this neatly expresses the current behaviors we already have. E.g.
if you don't specify the "addr-gen-mode" in a keyfile, "default-or-eui64"
is a pretty clear thing.
Note that usually we cannot change default values, in particular not for
libnm's properties. That is because we don't serialize the default
values to D-Bus/keyfile, so if we change the default, we change
behavior. Here we change from "stable-privacy" to "default" and
from "eui64" to "default-or-eui64". That means, the user only experiences
a change in behavior, if they have a ".conf" file that overrides the default.
https://bugzilla.redhat.com/show_bug.cgi?id=1743161https://bugzilla.redhat.com/show_bug.cgi?id=2082682
See-also: https://github.com/coreos/fedora-coreos-tracker/issues/907https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1213
We almost always do the wrong thing in interactive add:
The software devices generally require an interactive name, but we don't
insist of asking for them; treating them as optional:
$ nmcli -a c add type dummy
There is 1 optional setting for General settings.
Do you want to provide it? (yes/no) [yes]
For some interface types (bridges, bonds, ...) we make up a name, presumably
for historical reasons. But we don't give the user an option to modify
them:
$ nmcli -a c add type bridge
<not asking for interface name at all>
There are 9 optional settings for Bridge device.
Do you want to provide them? (yes/no) [yes]
This fixes the above use cases -- still set the default, but be sure to
ask:
$ nmcli -a c add type dummy
Interface name:
$ nmcli -a c add type bridge
Interface name [nm-bridge1]:
Beautiful.
Do the same bookkeeping as would happen upon setting the "type" option
when the connection has a connection.type set upon its addition.
Otherwise the --ask mode is sad:
$ nmcli --ask c add connection.type team
** nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Bail out! nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Aborted (core dumped)
After the connection's type is set, some bookkeeping is necessary for
the interactive (--ask) mode: appropriate setting need to be added and
options enabled.
Currently it happens in an option setter; which runs when the "type"
options is present on the command line, or the value is set in a
response to interactive mode:
$ nmcli --ask c add type team
$ nmcli --ask c add
Connection type: team
But not when the property is set directly:
$ nmcli --ask c add connection.type team
** nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Bail out! nm:ERROR:src/nmcli/connections.c:5648:connection_get_base_meta_setting_type: assertion failed: (base_setting)
Aborted (core dumped)
This doesn't fix the issue -- a followup commit (hopefully) will.
For new connections, this ensures the value in square brackets on
interactive add are always correct.
Apart from that, this allows us to initialize some non-default values
before asking (such as making up an interface name for some software
devices), and inform the user about what we picked:
Interface name [nm-bridge]:
This is slightly annoying:
$ nmcli -a c add type ethernet
There is 1 optional setting for General settings.
No point in asking if there's just one option. Just ask right away:
$ nmcli -a c add type ethernet
Interface name:
The interactive add is not too enthusiastic about not providing a value
in a list.
That is before on getting an empty line in ask_option() we take a
shortcut instead of dispatching to set_option(). That way we skip
setting the PROPERTY_INF_FLAG_DISABLED flag, causing the option to
be included in questionnaire_one_optional()'s info list.
There's no reason to avoid calling set_option() if we don't get a value;
set_option() handles NULL value just fine.
$ nmcli -a c add
Connection type: dummy
There is 1 optional setting for General settings.
Do you want to provide it? (yes/no) [yes]
Interface name [*]: lala
There are 2 optional settings for IPv4 protocol.
Do you want to provide them? (yes/no) [yes]
You can specify this option more than once. Press <Enter> when you're done.
IPv4 address (IP[/plen]) [none]:
You can specify this option more than once. Press <Enter> when you're done.
IPv4 address (IP[/plen]) [none]:
You can specify this option more than once. Press <Enter> when you're done.
IPv4 address (IP[/plen]) [none]:
...
This is not good:
$ nmcli device delete nm-bond
Segmentation fault (core dumped)
Fixes: 5f9d2927ed ("nmcli/devices: use GPtrArray from get_device_list() directly")
Distinguish a OWE-TM enabled BSS (which itself is unencrypted) from the
OWE BSS actually employing encryption.
Signed-off-by: David Bauer <mail@david-bauer.net>
Comments on the same line as field names are not rendered well by clang-format.
Even if manually edited, it seems not a preferable way to comment on a field.
Move the comment in the line before.
The property wait-activation-delay will delay the activation of an
interface the specified amount of milliseconds. Please notice that it
could be delayed some milliseconds more due to other events in
NetworkManager.
This could be used in multiple scenarios where the user needs to define
an arbitrary delay e.g LACP bond configure where the LACP negotiation
takes a few seconds and traffic is not allowed, so they would like to
use nm-online and a setting configured with this new property to wait
some seconds. Therefore, when nm-online is finished, LACP bond should be
ready to receive traffic.
The delay will happen right before the device is ready to be activated.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1248https://bugzilla.redhat.com/show_bug.cgi?id=2008337
This is an interface to the Checkpoint/Restore functionality that's
available for quite some time. It runs a command with a checkpoint taken
and rolls back unless success is confirmed before the checkpoint times
out:
$ nmcli dev checkpoint eth0 -- nmcli dev dis eth0
Device 'eth0' successfully disconnected.
Type "Yes" to commit the changes: No
Checkpoint was removed.
The details about how it's used are documented in nmcli(1) and
nmcli-examples(7).
When the input ends, we indeed eventually want to shut down.
Nevertheless, it might be that we terminated the input *because* we're
already shutting down and want do do our cleanup. Let's not take the
shortcut to nmc_exit() in case the main loop is no longer running.
This doesn't affect existing uses of nmc_readline(), but will be useful
in a future patch.
This makes get_device_list() return an array of NMDevices with a
reference taken and a destroy notifier that unhooks disconnect_state_cb,
so that it could replace the GSList of the same utility used by
disconnect/delete commands.
Suggested-by: Thomas Haller <thaller@redhat.com>
A pointer array is slightly more efficient here, since we don't really
need the ability to insert elements in the middle. In fact, we'd prefer
if we could just add to the end, so that we'd spare some callers from a
need to do a g_slist_reverse().
Even though that alone being a good reason to use a GPtrArray instead of
GSList, I'm doing this for so that I could actually use the returned value
as-is in a call to nm_client_checkpoint_create() in a future patch.
Don't consider "--" a device name. Instead, treat it as a signal to stop
reading the device list.
If a caller expects nothing beyond the device names, it now has to
check.
Prior to this patch, get_device_list() would give the caller no clue
about how many options did it consume. That is okay -- it would always
process all argument until the end, so the no callers would really care.
In a further patch, I'd like to allow termination of the device name
list (with a "--" arguments), so it will be possible to specify further
arguments.
Let's change the protype of this routine to use pointers to argc/argv,
that it will be possible to adjust them.
Introduction of a new setting ipv4.link-local, which enables
link-local IP addresses concurrently with other IP address assignment
implementations such as dhcp or manually.
No way is implemented to obtain a link-local address as a fallback when
dhcp does not respond (as dhcpd does, for example). This could be be
added later.
To maintain backward compatibility with ipv4.method ipv4.link-local has
lower priority than ipv4.method. This results in:
* method=link-local overrules link-local=disabled
* method=disabled overrules link-local=enabled
Furthermore, link-local=auto means that method defines whether
link-local is enabled or disabled:
* method=link-local --> link-local=enabled
* else --> link-local=disabled
The upside is, that this implementation requires no normalization.
Normalization is confusing to implement, because to get it really
right, we probably should support normalizing link-local based on
method, but also vice versa. And since the method affects how other
properties validate/normalize, it's hard to normalize that one, so that
the result makes sense. Normalization is also often not great to the
user, because it basically means to modify the profile based on other
settings.
The downside is that the auto flag becomes API and exists because
we need backward compatibility with ipv4.method.
We would never add this flag, if we would redesign "ipv4.method"
(by replacing by per-method-specific settings).
Defining a default setting for ipv4.link-local in the global
configuration is also supported.
The default setting for the new property can be "default", since old
users upgrading to a new version that supports ipv4.link-local will not
have configured the global default in NetworkManager.conf. Therefore,
they will always use the expected "auto" default unless they change
their configuration.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
We want to warn the user if they're connecting to an insecure network:
$ nmcli d wifi
IN-USE BSSID SSID MODE CHAN RATE SIGNAL BARS SECURITY
BA:00:6A:3C:C2:09 Secured Network Infra 2 54 Mbit/s 100 ▂▄▆█ WPA3
FA:7C:46:CC:9F:BE Ye Olde Wlan Infra 1 54 Mbit/s 100 ▂▄▆█ WEP
$ nmcli d wifi connect 'Ye Olde Wlan'
Warning: WEP encryption is known to be insecure.
...
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1224
The order of addresses matters. For "ipv4.addresses", the list
contains the primary address first. For "ipv6.addresses", the
order was reverted. This was also documented behavior.
The previous patch just changed behavior with respect to relative order
of static IPv6 addresses and autoconf6/DHCPv6. As we seem in the mood
for changing behavior, here is another one.
Now the addresses are interpreted in an order consistent with IPv4 and
how one might expect: preferred addresses first.
This adds a global "--offline" option and allows its use with "add" and
"modify" commands. The "add" looks like this:
$ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \
>output.nmconnection
The "modify" is essentially implementing what's been suggested by
Beniamino in bugzilla ticked (referred to below):
$ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \
<input.nmconnection >output.nmconnection
Other commands don't support the argument at the moment:
$ nmcli --offline c up ens3
Error: 'up' command doesn't support --offline mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1361145
Make the order of nmc_complete_strings() arguments consistent with the
multi-way conditional below. Doesn't have any effect, just ensures the
ommisions and mistakes are hopefully easier to spot.
Use bitfields to save a few bytes. This involves swapping gboolean for
bool and some reordering in order to get them grouped together.
The patch looks horrible, because clang-format decides to put itself and
seem to go out of its way to make this whole file look idiotic.
What can you do.
When no radio hardware is present in the system, "nmcli radio"
currently displays:
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
which is misleading. Use the new RadioFlags property to display
"missing" in the *-HW columns when there is no hardware for the
given radio technology.
https://bugzilla.redhat.com/show_bug.cgi?id=1996918
If we can't find a connection for any reason other than that it doesn't
exist, we should error out immediately and consistently, regardless of
whether we already encountered a non-existent connection.
