When activating a connection, it may fail with nmcli reporting:
$ nmcli connection up id "Wired Connection 1"
Error: Connection activation failed: Active connection removed before it was initialized
This should be easily reproducible by having a connection "Wired Connection 1" with
cloned-mac-address set to random. When the connection is already active on a device,
re-activating with
$ nmcli connection up id "Wired Connection 1"
fails.
We first create a queued-activation and tear down the existing
connection:
device (enp0s25): state change: deactivating -> disconnected (reason 'new-activation')
Shortly after we see:
device[0x557d02cdb0c0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, deactivate)...
device[0x557d02cdb0c0] (enp0s25): taking down device
later, we get:
device (enp0s25): link disconnected
device[0x557d02cdb0c0] (enp0s25): queued state change to unavailable due to carrier-changed (id 17290)
in the meantime, the queued activation request starts:
device (enp0s25): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e)
but the device already transitions to unavailable
device[0x557d02cdb0c0] (enp0s25): running queued state change to unavailable (id 17290)
device (enp0s25): state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
which kills the new activation request:
active-connection[0x557d02c10e40]: set state deactivated (was unknown)
Just delay a carrier-lost handling if we have any queued activation
requests.
(cherry picked from commit d4e9b30320)
When a assumed software device is brought down externally, it becomes
UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to
UNMANAGED. In such case, we shouldn't flush the IP configuration
(addresses and routes) present on the device.
To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify
nm_device_cleanup() not to flush addresses and devices with such flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1363995
(cherry picked from commit 45cd3302dc)
- don't include "nm-default.h" in header files. Every source file must
include as first header "nm-default.h", thus our headers get the
default include already implicitly.
- we don't support compiling NetworkManager itself with a C++ compiler. Remove
G_BEGIN_DECLS/G_END_DECLS from internal headers. We do however support
users of libnm to use C++, thus they stay in public headers.
(cherry picked from commit f19aff8909)
Instead of updating the device-statistic counters only periodically as
we refresh the link, update them on every link-changed event from
platform.
That means, also for devices that have RefreshRateMs at zero, the values
will be updated at random times when the link information changes.
The difference is, that previously the counters would be zero unless
RefreshRateMs was set. Now, they have some (probably stale) values
which however are not guaranteed to be kept up-to-date.
Also, now we refresh more often then promised by RefreshRateMs. But the API
technically doesn't specify that, so if we find there is a problem with
this, we may revert it later.
Originally, "nm-device-statistics.c" contained code to fetch the device
counters via netlink. As now the netlink part is handled by NMPlatform,
the code can be simplified by merging it back to NMDevice.
Add statistics interface to all device instances. When active, the
properties of this interface are refreshed whenever there is network
activity for the device.
Activation is performed by changing RefreshRateMs property. If set to
zero, the interface is deactivated. If set to other value, the rest of
the interface properties are refreshed whenever the related network
metric changes, being RefreshRateMs the minimum time between property
changes, in milliseconds.
Unfortunately teamd doesn't have an asynchronous way to notify a
change in the actual configuration, so when a port is enslaved or
released we wait some time for the changes to take effect and read the
configuration again.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
Request the actual configuration when reading it from teamd. The
actual configuration, differently from the normal one, doesn't contain
non-active team ports.
enables (back) matching against 802-3-ethernet.mac-address and
802-3-ethenet.mac-address-blacklist connection parameters
for MAC addresses belonging to virtual devices too.
On every start of NetworkManager I'd see a warning message:
modem-broadband[cdc-wdm0]: failed to retrieve SIM object: No SIM object available
Apparently, to warn about this is too alarming.
Commit f85941ee91 ("device: don't try to generate ipv6ll address for
disconnected devices") disabled the generation of IPv6 link-local
addresses for disconnected devices to fix a crash. However that broke
the following:
$ ip a f dev eth0
$ systemctl start NetworkManager
$ nmcli d
DEVICE TYPE STATE CONNECTION
eth0 ethernet disconnected eth0
$ ip a a dev eth0 2001::42/64
$ ip a show eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff
inet6 2001::42/64 scope global
valid_lft forever preferred_lft forever
(no link-local address)
Instead, enable the generation of a link-local address even if the
device is disconnected and fix nm_device_get_ip_iface_identifier() to
not require a connection if @ignore_token is set.
Fixes: f85941ee91
If the read of teamd configuration failed (possibly due to a timeout),
fail the connection immediately where possible instead of letting it
continue and risk to block again at the next read.
https://bugzilla.redhat.com/show_bug.cgi?id=1257237
When a device is activated any existing teamd instance is killed. But
since commit 28274495d6 ("device/team: always try to connect to
teamd in update_connection()") the disappearing of the D-Bus name
owner always triggers an automatic restart of the instance in
teamd_dbus_vanished() if the name was previously owned. This new
instance conflicts with the instance we're about to start.
Instead, restore the previous behavior of restarting teamd only if
there is an activation in progress and use @tdc as a flag. This also
means that update_connection() should not modify the value of @tdc.
Fixes: 28274495d6
When the master connection deactivates, we also fail slave
connections; but if the master deactivation happens just before a
slave reaches the PREPARE state, we failed to notice it and keep
the slave stuck without chance of progressing. Fix this.
Since nm_device_slave_notify_release() is called from outside the
activation chain of the slave device (it gets called from the master
device) there might be pending activation sources scheduled, clear
them before queueing a state change.
Previously we used defines for bond option names and used string
literals for their attribute names in sysfs. But they are the same by
definition so let's use defines also for attributes.
Even if the 'ad_actor_system' option is only valid for the 802.3ad
mode, the sysfs file is always present and has a default value of
''. But in 802.3ad mode the default value is
'00:00:00:00:00:00'. Return the correct value in
nm_setting_bond_get_option_default().
Furthermore, writing a empty string to the file will generate an
error, don't do it.
We print an error when the write of a bond options fails as this is
considered an effect of a wrong configuration (or a bug in the checks
done by NM) that the user should notice. But not all options are
supported in all bonding modes and so we ignore some unsupported
options for the current mode to avoid populating logs with useless
errors.
Improve the code there by using a more generic approach and
synchronize the mode/option compatibility table with kernel (file
drivers/net/bonding/bond_options.c).
https://bugzilla.gnome.org/show_bug.cgi?id=767776https://bugzilla.redhat.com/show_bug.cgi?id=1352131
If the device is disconnected because it can't be assumed due to lack
of IP configuration, don't try to generate an ipv6 link-local address,
as this requires a connection.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 __GI_abort () at abort.c:89
#2 g_assertion_message (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", message=message@entry=0x1e86100 "assertion failed: (connection)") at gtestutils.c:2429
#3 g_assertion_message_expr (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", expr=expr@entry=0x5e65c6 "connection") at gtestutils.c:2452
#4 nm_device_get_ip_iface_identifier (self=self@entry=0x1e612a0, iid=iid@entry=0x7fffce40e3d0, ignore_token=ignore_token@entry=1) at devices/nm-device.c:831
#5 check_and_add_ipv6ll_addr (self=self@entry=0x1e612a0) at devices/nm-device.c:5983
#6 queued_ip6_config_change (user_data=0x1e612a0) at devices/nm-device.c:9489
#7 g_main_dispatch (context=0x1d3e060) at gmain.c:3154
#8 g_main_context_dispatch (context=context@entry=0x1d3e060) at gmain.c:3769
#9 g_main_context_iterate (context=0x1d3e060, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#10 g_main_loop_run (loop=0x1d3ab00) at gmain.c:4034
#11 main (argc=1, argv=0x7fffce40e6a8) at main.c:411
https://bugzilla.redhat.com/show_bug.cgi?id=1351633
<info> [1467793329.6313] device (veth-guest): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e)
<debug> [1467793329.6313] device[0x55af2884bf90] (veth-guest): activation-stage: schedule activate_stage1_device_prepare,2 (id 510)
<warn> [1467793329.6314] device (veth-guest): disconnecting connection 'my-wired' for new activation request.
<info> [1467793329.6315] device (veth-guest): state change: disconnected -> deactivating (reason 'new-activation') [30 110 60
A warning is too verbose. This is not an unusual condition, it's just that
a new activation supersedes an other one.
- make NMDeviceWifi and NMDeviceWifiClass internal, opaque
structures
- embed private data in NMDeviceWifi
- implement GObject properties via NM_GOBJECT_PROPERTIES_DEFINE()
<warn> [1467730406.7343] device (wlp3s0): add_pending_action (2): scan already pending
file devices/nm-device.c: line 10443 (nm_device_add_pending_action): should not be reached
Fixes: eed8fd2e43
No longer typedef NMDeviceEthernet to NMDevice. We don't do that
for most other classes, and I think it is not a good pattern
(yes, the casts are cumbersome, but what can you do).
Also, embed a pointer to the private data in NMDeviceEthernet
for fast lookup and ease of debugging.
We should overwrite the constructed() method instead of hooking the
GObject creation via constructed(). That is much cleaner as at that
point the GObject is fully initialized.
Also, this avoids a pointless warning when trying to get the not yet
initialized GUdevDevice:
<debug> [1467714778.0958] platform: signal: link added: 15: eth0 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? not-init addrgenmode eui64 addr AA:BB:CC:DD:EE:FF driver e1000e
<warn> [1467714778.0961] device (eth0): failed to find device 15 'eth0' with udev
<debug> [1467714778.0962] device[0x562eac10ee50] (eth0): constructed (NMDeviceEthernet)
...
<debug> [1467714778.1334] platform: signal: link changed: 15: enp0s25 <DOWN;broadcast,multicast> mtu 1500 arp 1 ethernet? init addrgenmode eui64 addr AA:BB:CC:DD:EE:FF driver e1000e
Trying to set a property on a device that does not exist is not something
necessarily wrong. Don't print error/warning messages.
<trace> [1467707267.2887] device[0x55a74adbdaf0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, unmanage)...
<debug> [1467707267.2887] platform: link: setting '(null)' (2) hardware address
<debug> [1467707267.2887] platform-linux: link: change 2: address: 68:F7:28:61:68:F7 (6 bytes)
<debug> [1467707267.2887] platform-linux: do-request-link: 2
<debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 226
<debug> [1467707267.2888] platform-linux: netlink: recvmsg: error message from kernel: No such device (19) for request 227
<error> [1467707267.2888] platform-linux: do-change-link[2]: failure changing link: failure 19 (No such device)
<warn> [1467707267.2888] device (enp0s25): set-hw-addr: failed to reset MAC address to 68:F7:28:61:68:F7 (unmanage)
