On some kernels (at least RHEL-7.2) we receive a spurious RTM_NEWLINK
message after the RTM_DELLINK message for deleting a bond master.
On RHEL-7, the following commands give:
# ip link add dummy0 type dummy
# ip link add bond0 type bond
# ip link set bond0 up
# ip link set dummy0 master bond0
# ip monitor link &
# ip link del bond0
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
Deleted 21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
^^^^^^^^^^^^^^^ RTM_NEWLINK after RTM_DELLINK (and there follows no
RTM_DELLINK afterwards)
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
Fix that by reverting clear_REFRESH_LINK(). This fix has two downsides:
- on kernels where this hack is not necessary, we unnecessarily refetch
a link
- the platform cache first removes the link, adds it again and removes
it. This is ugly, but should have no real consequences because all
listeners to the platform signals delay processing the signals to an
idle handler.
https://bugzilla.redhat.com/show_bug.cgi?id=1285719
This reverts commit f4f4e1cf09.
The related bug rh#1262908 in kernel causes missing netlink notifications
when moving a IFA_LINK interface to another netns.
Add a test for our workaround.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1262908
The related bug rh#1285827 in kernel causes a missing IFLA_LINK/parent
attribute when creating a veth pair:
# ip monitor link &
[1] 6745
# ip link add dev vm1 type veth peer name vm2
30: vm2@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether be:e3:b7:0e:14:52 brd ff:ff:ff:ff:ff:ff
31: vm1@vm2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
link/ether da:e6:a6:c5:42:54 brd ff:ff:ff:ff:ff:ff
Add a workaround and test.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1285827
Due to kernel bugs [1], the first netlink event about a new link
sometimes lacks the IFLA_LINKINFO with the link-type lnk data.
In the case the data is missing, schedule a re-fetch the link
hoping that it gets send.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1284001
"platform" implements a iproute2 like command-line
tool based on NMPlatform.
It is badly maintained and mostly unused. If we want
to test something, we should write tests that are run
automatically during `make check`. Manual tests just
don't fly.
Can't just substitute sysconfdir into a header file -- it's meant to be
expanded in a Makefile. Otherwise, unexpanded ${prefix} will end up in a
header file.
We do that for NMCONFDIR already, let's use it here too.
Fixes: 2144457fab
Instead of reimplementing constructed() just to call
nm_exported_object_export(), use the 'export_on_construction' flag
which does this automatically. This also fixes the following error:
nm_exported_object_export: assertion failed: (priv->_constructed)
Fixes: 8a8ecc46ca
When @src didn't have a gateway and @dst did, the function left @dst's
gateway set to 0.0.0.0; fix this and unset the gateway in such case.
Fixes: 063677101a
The dhclient DHCP backend strips the domain part from the hostname
option sent to server; for consistency among different backends
uniform the dhcpcd client to do the same.
The dhclient DHCP backend strips the domain part from the hostname
option sent to server; for consistency among different backends
uniform the internal client to do the same.
The DHCP client from new libsystemd-network requires a link-local IPv6
address to be passed to the library; add a new argument to
nm_dhcp_manager_start_ip6() and related functions.
When deconfiguring a device, we must also explicitly clear the
default-route -- unless the device was assumed.
This can easily reproduced by disconnecting the cable from the
wired connection that has the default rout. Prevously, the
default-route was not cleared and lingered around.
https://bugzilla.gnome.org/show_bug.cgi?id=757587
Even if update_seen_bssids_cache() is called by set_current_ap() it did not
really update the cache because it was called in NM_DEVICE_STATE_PREPARE state.
So the cache was only updated by periodic_update() when the connection roamed
to another AP.
Fixes: 1283816b41https://bugzilla.redhat.com/show_bug.cgi?id=1094298
The nm_supplicant_config_add_*() functions used to log failures
themselves. As also the caller was logging the failure this resulted
in duplicate logging lines like:
<warn> MAC address randomization is not supported
<error> [1447867727.909185] [nm-device-wifi.c:2238] build_supplicant_config(): (wlp3s0): Couldn't add 802-11-wireless setting to supplicant config.
<error> [1447867727.909261] [nm-device-wifi.c:2472] act_stage2_config(): (wlp3s0): Activation: (wifi) couldn't build wireless configuration.
Instead, propagate the error reason back to the caller where there
is more context to log one single concise message.
Now you'd see only:
<error> [1447935996.859371] [nm-device-wifi.c:2475] act_stage2_config(): (wlp3s0): Activation: (wifi) couldn't build wireless configuration: 802-11-wireless: cannot enable mac-randomization due to missing supplicant support
Modems often don't expose all the required properties until they have
been unlocked, and that includes the IP types supported by the modem.
With an autoconnect WWAN connection where the SIM requires a PIN, there
were two problems:
1) the PIN is a secret and we don't have it until it's explicitly requested
during the activation process, so we cannot gate GSM connection availability
on whether a PIN is present since this happens long before we request secrets
2) when the modem is locked it may not report the supported IP types, which
caused an auto-activation to fail early becuase IP compatibility is checked
before the PIN is sent to the modem
Rework connection activation flow into a series of concrete steps, where the
PIN is sent to the modem if required, and only after the modem is actually
unlocked does the connection proceed. This does mean that any connection
marked 'autoconnect' can theoretically enable a PIN-locked modem even if
the connection has no PIN defined, but there's no good way around that.
NetworkManager would activate the connection
Device subclasses can call nm_device_recheck_available() at any time,
and the function would change the device's state to UNKNOWN in cases
where the device was available already. For WWAN devices, availability
is rechecked every time the modem state changes, resulting in:
NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'disabled' --> 'enabling' (reason: user-requested)
NetworkManager[28919]: <debug> [1445538582.116727] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown
NetworkManager[28919]: <info> (ttyUSB4): modem state changed, 'enabling' --> 'searching' (reason: user-requested)
NetworkManager[28919]: <debug> [1445538582.776317] [devices/nm-device.c:2769] recheck_available(): [0x23bd710] (ttyUSB4): device is available, will transition to unknown
These properties limit whether the connection applies to a certain WWAN modem
based on the modem's device ID or SIM ID (as reported by the WWAN management
service), or through the MCC/MNC ID of the operator that issued the SIM card.
Old init-scripts that did not yet understand this key will have
mac-address-randomization explicitly disabled. This is to ensure
that old connections don't change behavior.
Thus, the writer must always write the value explicitly.
Downside is, if somebody creates a quick ifcfg-file, the feature
is disabled by default.
If the supplicant supports it and the connection requests it, tell
the supplicant to randomize the MAC address for the association.
In addition, like both iOS, Android, and other OSs always randomize
the MAC address when performing a WiFi scan.
NMExportedObject now derives from GDBusObjectSkeleton, which is what
GDBusObjectManagerServer wants. The main GDBusConnection and each
private server connection now gets a new GDBusObjectManagerServer,
and exported objects are registered with that instead of individually
exporting each GDBusInterfaceSkeleton.
Previously exported objects were not referenced by the BusManager,
but instead removed from the exports hash via weak references. The
GDBusObjectManagerServer instead references exported objects, which
can make them live much longer than they did before.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
With ObjectManager we can not export ObjectSkeletons to multiple connections --
the manager would unexport the InterfaceSkeletons upon its destruction.
It seems easiest to just drop the private socket altogether; It was broken for
broken for some time and noone noticed anyway. Also startup before D-Bus is
still broken: NetworkManager would reconnect to the bus but multiple managers
won't notice the bus is around (we'll never see firewalld or policykit come up).
We should probably just stop pretending we support operation without a real
D-Bus server. With the advent of kdbus this makes even more sense.
In debug-mode, test_ip4_address_peer_zero() used to print the
result of `ip address show`. That fails for fake-platform
because the device does not exists.
Just don't do that.
