It seems more useful to have a best effort approach and configure
everything we can; in that way we achieve at least some connectivity,
and then sysadmin can check the logs in case something is
missing. Currently instead, the whole activation fails (so, no address
is configured) if just one of the addresses fails DAD.
Ideally, we should have a way to make this configurable; but for now,
implement the more useful behavior as default.
A duplicate address is a serious issue which leads to non-working
setups or problems hard to debug.
Enable IPv4 duplicate address detection (aka ACD, RFC 5227) by default
with a maximum timeout of 3 seconds.
IPv4 and IPv6 DAD work slightly differently: for IPv4 the presence or
absence of carrier doesn't have any effect on the duration of the
probe; for IPv6, DAD never completes without carrier because kernel
never removes the tentative flag.
In both cases, we shouldn't ignore the DAD result because that would
mean that we complete the ipmanual method without addresses actually
configured.
We don't know the reason why the DHCP client is being stopped. It is
wrong to schedule a commit of type "update" because the device could
be now unmanaged. Schedule instead a commit of type "auto", which
automatically determines the type of commit based on registered
handles.
If a commit is invoked without any change to the l3cd or to the ACD
data, in _l3cfg_update_combined_config() we skip calling
_l3_acd_data_add_all(), which should clear the dirty flag from ACDs.
Therefore, in case of such no-op commits the ACDs still marked as
dirty - but valid - are removed via:
_l3_commit()
_l3_acd_data_process_changes()
_l3_acd_data_prune()
_l3_acd_data_prune_one()
Invoking a l3cfg commit without any actual changes is allowed, see the
explanation in commit e773559d9d ('device: schedule an idle commit
when setting device's sys-iface-state').
The bug is visible by running test 'bond_addreses_restart_persistence'
with IPv4 ACD/DAD is enabled by default: after restart IPv6 completes
immediately, the devices becomes ACTIVATED, the sys-iface-state
transitions from ASSUME to MANAGED, a commit is done, and it
incorrectly prunes the ACD data. The result is that the IPv4 address
is never added again.
Fix this by doing the pruning only when we update the dirty flags.
Interfaces with IFF_NOARP don't support Address Conflict Detection,
which is based on ARP. Trying to start ACD on them would result in
ENOBUFS always being returned by send(), and n-acd handles such error
by retrying indefinitely.
On interfaces not supporting ACD (for example, layer3 interfaces), the
probe fails to be created with message:
l3cfg[...,ifindex=2]: acd[172.25.17.1, init]: probe-good (interface does not support acd, initial post-commit)
l3cfg[...,ifindex=2]: acd[172.25.17.1, ready]: set state to ready (probe is ready, waiting for address to be configured)
During the post-commit event, if the address is not yet configured, we
need to schedule a new commit to actually add it.
Currently, all the probes of an acd instance share the same seed
state. This means that the state is updated by all the probes, and as
a consequence they get different jitters for the wait timeouts;
therefore the order in which addresses become available (and are
configured on the interface) is not deterministic.
Keep a separate seed state for each probe, initialized from the acd
seed. This ensures that all the probes use the same timeouts when
sending probe requests, and that in case of no collision, addresses
are available in the order of probe start.
Currently, IPv4 shared mode fails to start when DAD is enabled because
dnsmasq tries to bind to an address that is not yet configured on the
interface. Delay the start of dnsmasq until the shared4 l3cd is ready.
Yes, there probably are not multiple threads here. It's a matter of principle to
not use smelly functions.
Also, copy the "errno" value we want to print, before calling various functions.
We have nm_strerror_native_r(), which is the wrapper around strerror_r() that
we want to use in glib components (it also will ensure that the string is valid
UTF-8). However, it's not usable from non-glib components.
Move the part that abstracts strerror_r() out to libnm-std-aux as _nm_strerror_r().
The purpose is that non-glib componenent can use the thread-safe wrapper around
strerror_r().
Systemd does not use strerror(), so this define was unused.
Even if it would use it, we would better patch the upstream
sources, as strerror() is not suitable in multi-threadded applications.
Show all valid properties for ip-tunnel.mode, not only 2 examples.
Show constants as values suitable for user input in nmcli. That means
showing, for example, "ipip (1)" instead of "IP_TUNNEL_MODE_IPIP (1)".
f-string is not supported in python2, and the autotool build complains
about it as follows:
```
LIBTOOL="/bin/sh ./libtool" "../src/tests/client/test-client.sh" "." ".." "python2" -- TestNmCloudSetup
File "/builds/NetworkManager/NetworkManager/src/tests/client/test-client.py", line 722
return f"{major}.{minor}.{micro}"
^
SyntaxError: invalid syntax
test-client.py failed!!
make[3]: *** [check-local-tests-client] Error 1
File "/builds/NetworkManager/NetworkManager/src/tests/client/test-client.py", line 722
return f"{major}.{minor}.{micro}"
^
SyntaxError: invalid syntax
test-client.py failed!!
```
Also, python2 complains about extra comma during argument unpacking.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1718
When rolling back a checkpoint, NM will crash due to dereference a NULL
pointer of `priv->removed_devices->len`.
To fix it, we just place a NULL check before that code block.
Fixes: 1f1b71ad9f ('checkpoint: preserve devices that were removed and
readded')
Reference: https://issues.redhat.com/browse/RHEL-1526
Signed-off-by: Gris Ge <fge@redhat.com>
The device authentication request is an async process, it can not know
the answer right away, it is not guarantee that device is still
exported on D-Bus when authentication finishes. Thus, do not return
SUCCESS and abort the authentication request when device is not alive.
https://bugzilla.redhat.com/show_bug.cgi?id=2210271
When we register the auto-activate, the device has to be registered in
NMPolicy, the assertion is correct and ensure that.
This reverts commit 712729f652.
It's not strictly necessary, because GObject.constructed() is
intentionally a NOP, to optionally allow chaining the parent method.
However, for consistency, this is what we commonly do.
l3cfg emits a log for ACD conflicts. However, l3cfg is not aware of
what are the related NMDevice or the currently active connection, and
so it can't log the proper metadata fields (NM_DEVICE and
NM_CONNECTION) to the journal.
Instead, let NMDevice log about ACD collisions; in this way, it is
possible to get the message when filtering by device and connection.
For example:
$ journalctl -e NM_CONNECTION=d1df47be-721f-472d-a1bf-51815ac7ec3d + NM_DEVICE=veth0
<info> device (veth0): IP address 172.25.42.1 cannot be configured because it is already in use in the network by host 00:99:88:77:66:55
<info> device (veth0): state change: ip-config -> failed (reason 'ip-config-unavailable', sys-iface-state: 'managed')
<warn> device (veth0): Activation: failed for connection 'veth0+'
When a collision is detected by the Address Conflict Detection
mechanism, store the conflicting MAC address in NML3AcdAddrInfo, so
that it is available to listeners of NML3Cfg for events of type
NM_L3_CONFIG_NOTIFY_TYPE_ACD_EVENT.
When updating NetworkManager to a new version, normally the service is
not restarted by the installer to avoid interrupting networking.
However, next nmcli invocation will use the updated version, but against
the older version of the daemon that is still running. Although this is
suposed to work, it is advisable that nmcli and daemon's versions are
the same. Emit a warning recommending restarting the daemon.
Add nmcli test to check the new feature. To avoid breaking the existing
tests, test-networkmanager-service now reports the same version than the
running nmcli except if it's instructed to report a different one.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1703
(cherry picked from commit fb851f3294)
When a device belonging to a checkpoint is removed, we clear the
device pointer from the DeviceCheckpoint and move the object from the
devices list to the removed-devices list of the checkpoint.
Later, when restoring the connection we need to set again the device
pointer in DeviceCheckpoint; otherwise, any connection on that device
can't be reactivated if changed.
Fixes: 0e2f7ac7b5 ('nm-checkpoint: drop reference to NM_DEVICE objects on removal signal')
(cherry picked from commit b80a398306)
With flag DISCONNECT_NEW_DEVICES, on rollback we delete devices that
are present in the system and are not in the checkpoint.
The problem is that we remove the device from
`NMCheckpointPriv->devices` when it is deleted and so we lose the
information that the device was in the checkpoint. We need to also
look in the `removed_devices` list.
Fixes: 0e2f7ac7b5 ('nm-checkpoint: drop reference to NM_DEVICE objects on removal signal')
(cherry picked from commit 0fcfd6e24f)
