If teamd crashes, we restore it. That's very nice, but if it really
crashed then it left ports attached and the slave connections are not
going to fail and the port configuration (e.g. priority or link watcher) in
teamd's memory will be gone.
This will restore the port configuration when the teamd connection is
re-established. This probably also fixes a race where a slave connection
would be enslaved (only possible externally and manually?) while we
didn't establish a connection to teamd yet. We'll just send the port
configuration in once're connected.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1361
Add option to set ofport_request when configuring ovs interface. When
connection with ofport_request configured is activated ovsdb will first
try to activated on the port set by ofport_request.
the .h.in file is not formatted by our nm-code-format.sh
file. It also contains .in template parameters that the
formatting would destroy.
Still, follow our current style and reformat the parts manually.
Because, why not?
The client side determines the UUID, so there is no security implication
by letting the nmcli user explicitly choose it.
$ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
Connection 'x' (6965f79c-4424-4918-98e8-3c0982434011) successfully added.
$ nmcli connection add type ethernet con-name x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
Error: Failed to add 'x' connection: a connection with this UUID already exists
$ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434011
$ nmcli connection modify x connection.uuid 6965f79c-4424-4918-98e8-3c0982434012
Error: failed to modify connection.uuid: the property can't be changed.
It is useful to modify the UUID in offline mode. Otherwise, it's
cumbersome to clone a profile, because the cloned profile will
have the same UUID (and NetworkManager cannot load them both
at the same time).
umask 077
nmcli --offline connection modify \
connection.id profile2 \
connection.uuid new \
< /etc/NetworkManager/system-connections/profile1.nmconnection \
> /etc/NetworkManager/system-connections/profile2.nmconnection \
The doctext doesn't actually work for `man nm-settings-nmcli`. The
generation of our docs is still an incomprehensible mess that needs
fixing.
We really should not pass bogus values "1, 0" to g_set_error().
As we don't care about a particular error code, use
NM_UTILS_ERROR_UNKNOWN.
While at it, use nm_utils_error_set() everywhere.
Try to first use a stack allocated buffer for the temporary string.
Only if the data is too large, NMStrBuf will automatically grow
the buffer on the heap.
In many cases, this buffer will be large enough, and we can avoid the
heap allocation.
- move the second g_file_test() inside the if-block. No need to check
twice, if the file exists.
- load_one_nic() can return NULL. Use nm_g_hash_table_lookup() to avoid
NULL pointer assertion.
- use cleanup attribute for "nic" variable, and explicitly pass
ownership on with g_steal_pointer().
The user might still want to see the scan list, to decide whether to
stop the hotspot/ADHOC connection and connect to something else.
Allow explicit scans.
ModuleNotFoundError was only introduced in later python 3 versions.
Use just "ImportError", which is the parent class anyway.
Fixes: f7e484c8ed ('tests: fix "test-client.py" ignoring missing "NM" module')
If the MAC changes there is the possibility that the DHCP client will
not be able to renew the address because it uses the old MAC as
CHADDR. Depending on the implementation, the DHCP server might use
CHADDR (so, the old address) as the destination MAC for DHCP replies,
and those packets will be lost.
To avoid this problem, restart the DHCP client when the MAC changes.
https://bugzilla.redhat.com/show_bug.cgi?id=2110000
nm_utils_enum_to_str() can print flags, that is, combinations of
powers of two integers.
It also supports nicks, for certain flags.
When we have a nick for value zero, then that requires special
handling. Otherwise, that zero nick will always show up in the
string representation, although, it should only be used if the
enum value is exactly zero.
1) The "enabled-on-global-iface" flag was odd. Instead, have only
and "enabled" flag and skip (by default) endpoints on interface
that have no default route. With the new flag "also-without-default-route",
this can be overruled. So previous "enabled-on-global-default" now is
the same as "enabled", and "enabled" from before behaves now like
"enabled,also-without-default-route".
2) What was also odd, as that the fallback default value for the flags
depends on "/proc/sys/net/mptcp/enabled". There was not one fixed
fallback default, instead the used fallback value was either
"enabled-on-global-iface,subflow" or "disabled".
Usually that is not a problem (e.g. the default value for
"ipv6.ip6-privacy" also depends on use_tempaddr sysctl). In this case
it is a problem, because the mptcp-flags (for better or worse) encode
different things at the same time.
Consider that the mptcp-flags can also have their default configured in
"NetworkManager.conf", a user who wants to switch the address flags
could previously do:
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled-on-global-iface,signal,subflow
but then the global toggle "/proc/sys/net/mptcp/enabled" was no longer
honored. That means, MPTCP handling was always on, even if the sysctl was
disabled. Now, "enabled" means that it's only enabled if the sysctl
is enabled too. Now the user could write to "NetworkManager.conf"
[connection.mptcp]
connection.mptcp-flags=0x32 # enabled,signal,subflow
and MPTCP handling would still be disabled unless the sysctl
is enabled.
There is now also a new flag "also-without-sysctl", so if you want
to really enable MPTCP handling regardless of the sysctl, you can.
The point of that might be, that we still can configure endpoints,
even if kernel won't do anything with them. Then you could just flip
the sysctl, and it would start working (as NetworkManager configured
the endpoints already).
Fixes: eb083eece5 ('all: add NMMptcpFlags and connection.mptcp-flags property')
LTO without assertion enabled, thinks that certain code paths
result in uninitialized code. Technically, it's not wrong, in practice
those are only in cases where we already failed an assertion.
In function 'nm_ip_addr_is_null',
inlined from 'canonicalize_ip_binary' at src/libnm-core-impl/nm-setting-ip-config.c:67:21,
inlined from 'nm_ip_route_set_next_hop_binary' at src/libnm-core-impl/nm-setting-ip-config.c:1062:23:
./src/libnm-glib-aux/nm-inet-utils.h:80:12: error: 'a' may be used uninitialized [-Werror=maybe-uninitialized]
80 | return IN6_IS_ADDR_UNSPECIFIED(&a.addr6);
| ^
src/libnm-core-impl/nm-setting-ip-config.c: In function 'nm_ip_route_set_next_hop_binary':
./src/libnm-glib-aux/nm-inet-utils.h:73:14: note: 'a' declared here
73 | NMIPAddr a;
| ^
Try to workaround that by letting nm_utils_addr_family_to_size() always
return a non-zero size. This is ugly, because in the assertion case fail
we might now also get an additional memory corruption that could have
been avoided by returning zero. However, it probably doesn't matter, because
in this scenario we are already in a bad situation.
Fixes: b02aeaf2f3 ('glib-aux: fix various nm_ip_addr_*() functions for unaligned addresses')
Most of our nm_ip_addr_*() functions take an opaque pointer, that
can be either in_addr_t, struct in6_addr or NMIPAddr.
They also tend to support that their argument pointer is not aligned.
The reason is not very strong, except that usually it's simple to
support and it allows the caller to use those low-level functions for
pointers of unknown alignment (e.g. from a package on the network).
Fix a few cases for that.
- name things related to `in_addr_t`, `struct in6_addr`, `NMIPAddr` as
`nm_ip4_addr_*()`, `nm_ip6_addr_*()`, `nm_ip_addr_*()`, respectively.
- we have a wrapper `nm_inet_ntop()` for `inet_ntop()`. This name
of our wrapper is chosen to be familiar with the libc underlying
function. With this, also name functions that are about string
representations of addresses `nm_inet_*()`, `nm_inet4_*()`,
`nm_inet6_*()`. For example, `nm_inet_parse_str()`,
`nm_inet_is_normalized()`.
<<<<
R() {
git grep -l "$1" | xargs sed -i "s/\<$1\>/$2/g"
}
R NM_CMP_DIRECT_IN4ADDR_SAME_PREFIX NM_CMP_DIRECT_IP4_ADDR_SAME_PREFIX
R NM_CMP_DIRECT_IN6ADDR_SAME_PREFIX NM_CMP_DIRECT_IP6_ADDR_SAME_PREFIX
R NM_UTILS_INET_ADDRSTRLEN NM_INET_ADDRSTRLEN
R _nm_utils_inet4_ntop nm_inet4_ntop
R _nm_utils_inet6_ntop nm_inet6_ntop
R _nm_utils_ip4_get_default_prefix nm_ip4_addr_get_default_prefix
R _nm_utils_ip4_get_default_prefix0 nm_ip4_addr_get_default_prefix0
R _nm_utils_ip4_netmask_to_prefix nm_ip4_addr_netmask_to_prefix
R _nm_utils_ip4_prefix_to_netmask nm_ip4_addr_netmask_from_prefix
R nm_utils_inet4_ntop_dup nm_inet4_ntop_dup
R nm_utils_inet6_ntop_dup nm_inet6_ntop_dup
R nm_utils_inet_ntop nm_inet_ntop
R nm_utils_inet_ntop_dup nm_inet_ntop_dup
R nm_utils_ip4_address_clear_host_address nm_ip4_addr_clear_host_address
R nm_utils_ip4_address_is_link_local nm_ip4_addr_is_link_local
R nm_utils_ip4_address_is_loopback nm_ip4_addr_is_loopback
R nm_utils_ip4_address_is_zeronet nm_ip4_addr_is_zeronet
R nm_utils_ip4_address_same_prefix nm_ip4_addr_same_prefix
R nm_utils_ip4_address_same_prefix_cmp nm_ip4_addr_same_prefix_cmp
R nm_utils_ip6_address_clear_host_address nm_ip6_addr_clear_host_address
R nm_utils_ip6_address_same_prefix nm_ip6_addr_same_prefix
R nm_utils_ip6_address_same_prefix_cmp nm_ip6_addr_same_prefix_cmp
R nm_utils_ip6_is_ula nm_ip6_addr_is_ula
R nm_utils_ip_address_same_prefix nm_ip_addr_same_prefix
R nm_utils_ip_address_same_prefix_cmp nm_ip_addr_same_prefix_cmp
R nm_utils_ip_is_site_local nm_ip_addr_is_site_local
R nm_utils_ipaddr_is_normalized nm_inet_is_normalized
R nm_utils_ipaddr_is_valid nm_inet_is_valid
R nm_utils_ipx_address_clear_host_address nm_ip_addr_clear_host_address
R nm_utils_parse_inaddr nm_inet_parse_str
R nm_utils_parse_inaddr_bin nm_inet_parse_bin
R nm_utils_parse_inaddr_bin_full nm_inet_parse_bin_full
R nm_utils_parse_inaddr_prefix nm_inet_parse_with_prefix_str
R nm_utils_parse_inaddr_prefix_bin nm_inet_parse_with_prefix_bin
R test_nm_utils_ip6_address_same_prefix test_nm_ip_addr_same_prefix
./contrib/scripts/nm-code-format.sh -F
Various synchronous methods (D-Bus calls) in libnm's NMClient API were
deprecated. The problem is that NMClient contains a cache of D-Bus
objects, and it gets updated by asynchronous events (D-Bus signals).
Those events get only processed when iterating the GMainContext, but
they are ordered.
When we perform a pseudo blocking D-Bus call with
g_dbus_connection_call_sync(), then GDBus creates a temporary
GMainContext, sends the request and iterates the internal context
blocking for the response. That is, this reply is not synchrounized with
the events that update the NMClient cache.
That is a problem for methods like nm_remote_connection_delete(),
because you call blocking delete, but afterwards the object is still in
the NMClient cache. That's why most blocking methods are deprecated.
While such blocking calls are therefore problematic, they can still be
very convenient to call from a simple script, a test tool or the python
REPL. See "examples/python/gi/nm-wg-set" which calls
nm_remote_connection_get_secrets(), and it would be (unnecessarily)
cumbersome to do the correct thing or using async API.
In particular, nm_remote_connection_get_secrets() doesn't retrieve an object
that is in the NMClient cache in the first place. Sure, the result is
out of order with the cache, but it's not obviously related and in most
cases it wouldn't matter to the user. So undeprecate this function again.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1345
Try work around the issue documented by Emil Velikov in
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1264
When we mirror an 802.1x connection to an IWD config file and there's an
AP in range with matching SSID, that connection should become available
for activation. In IWD terms when an 802.1x network becomes a Known
Network, it can be connected to using the .Connect D-Bus method.
However there's a delay between writing the IWD config file and receiving
the InterfaceAdded event for the Known Network so we don't immediately
find out that the network can now be used. If an NM client creates a
new connection for an 802.1x AP and tries to activate it quickly enough,
NMDeviceIWD will not allow it to because it won't know the network is
known yet. To work around this, we save the SSIDs of 802.1x connections
we recently mirrored to IWD config files, for an arbitrary 2 seconds
period, and we treat them as Known Networks in that period since in
theory activations should succeed.
The alternative proposed in the !1264 is to drop NMDeviceIWD checks that
there's a Known Network for the 802.1x connection being activated since
IWD will eventually perform the same checks and IWD is the ultimate
authority on whether the profile is IWD-connectable.
The IWD backend would originally use .Disconnect() on IWD dbus "Station"
objects to make sure IWD is out of autoconnect or that it isn't
connecting to a network that NM didn't command. Later the default became
to let IWD run autoconnect so now most of the time the backend just
mirrors IWD's state to NMDevice's state.
Now sometimes when NMDevice still seems to have an active connection but
IWD has gone through one or more state changes (which we may see after a
delay due to D-Bus) and is now connected to or connecting to a different
network, NMDevice would first have to go through .deactivate to mirror
the fact the original connection is no longer active, and it'd use
.Disconnect() which could break the new connection, so check for this
situation.
