ip4_addr_subnets_is_secondary() should fill the list of addresses in
the same subnet also when returning FALSE, because
nm_platform_ip4_address_sync() uses it.
Fixes: 2f68a50041
(cherry picked from commit a347962831)
nm_platform_ip4_address_sync() tries to apply the new configuration
with the minimum effort and doesn't delete addresses if they are
already present on the interface. This can break the ordering, as an
existing address would be promoted by kernel to primary, even if it
was last in our configuration.
Add some logic to ensure the correct order of addresses is always
enforced. This fixes situations like:
# nmcli connection add type ethernet ifname eth0 con-name t \
ipv4.method manual \
ipv4.addresses "1.1.1.1/24,1.1.1.2/24,1.1.1.5/24"
# nmcli connection up t
=> addresses are applied in the right order:
inet 1.1.1.1/24 brd 1.1.1.255 scope global eth0
inet 1.1.1.2/24 brd 1.1.1.255 scope global secondary eth0
inet 1.1.1.5/24 brd 1.1.1.255 scope global secondary eth0
# nmcli connection mod t ipv4.addresses "1.1.1.5/24,1.1.1.2/24,1.1.1.1/24"
# nmcli device reapply eth0
=> order is wrong:
inet 1.1.1.2/24 brd 1.1.1.255 scope global eth0
inet 1.1.1.5/24 brd 1.1.1.255 scope global secondary eth0
inet 1.1.1.1/24 brd 1.1.1.255 scope global secondary eth0
Co-Authored-By: Thomas Haller <thaller@redhat.com>
(cherry picked from commit 2f68a50041)
We no longer use wpa_supplicant for MAC address randomization. Instead, NetworkManager
handles it on it's own. It is actually important that supplicant does not interfere
when setting the MAC address of the device.
The code was only in effect when supplicant has a PreassocMacAddr property.
As this is a recent feature, the left-over code wasn't noticed until now.
https://mail.gnome.org/archives/networkmanager-list/2017-February/msg00003.html
Fixes: 767abfa690
(cherry picked from commit 0cb85f161e)
(cherry picked from commit 7ada0e0bc3)
With commit 4f6c91d696, we aimed to
enable mac-address-randomization by default for Wi-Fi. That however
is not possible by default because it breaks various scenarios.
Also, later wifi.mac-address-randomization was deprecated in favor
of wifi.cloned-mac-address setting.
Both wifi.mac-address-randomization and wifi.cloned-mac-address support
global default values, so it is wrong to read a missing
MAC_ADDRESS_RANDOMIZATION setting as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
See also commit 46d53e1101 which does
something similar for keyfile.
This bug also prevents a user from clearing the cloned-mac-address:
$ nmcli connection show "$CONN"
...
802-11-wireless.cloned-mac-address: permanent
802-11-wireless.mac-address-randomization: never
...
$ nmcli connection modify "$CONN: wifi.cloned-mac-address ''
# ^ takes no effect
As workaround, you also need to clear mac-address-randomization:
$ nmcli connection modify "$CONN: wifi.cloned-mac-address '' \
wifi.mac-address-randomization default
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00060.html
(cherry picked from commit 27cba47957)
(cherry picked from commit 491ccd9d64)
At least with my supplicant, the capability is called
all-upper-case "FAST".
The check used case-insensitive, but that was broken
by a previous change.
Fixes: 9f5f141100
(cherry picked from commit 66ff601ecf)
(cherry picked from commit 1caae3743d)
We used MASTER, BRIDGE and TEAM_MASTER keys for a differnet purpose than the
network.service did, confusing the legacy tooling. Let's do our best to write
compatible configuration files:
* Add *_UUID properties that won't clash with initscripts
* Ignore non-*_UUID keys on read if *_UUID is present
* If the connection.master is an UUID of a connection with a
connection.interface-name, write the uuid into the *_UUID key while setting
the non-*_UUID key to the interface name for compatibility
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
(cherry picked from commit 8b7b0d3fc2)
Move the updating/setting of the ip-ifindex/ip-iface to one place.
Properties should be for the most part immutable/read-only, and only
at particular places modified. That way, it's easier to track who
changes a property.
Also, add a logging line with "ip-ifname" prefix.
https://mail.gnome.org/archives/networkmanager-list/2017-January/msg00011.html
(cherry picked from commit 78017f1bdc)
The kernel already takes care of adding and updating temporary
addresses when an address with IFA_F_MANAGETEMPADDR flag is added or
updated; doing it also in nm_platform_ip6_address_sync() can overwrite
the changes done by kernel, especially because since commit
0a0bca9c7f ("ip6-config: sort addresses only when reading the
property value") there is no guarantee that temporary addresses are
before the public ones in the IPv6 configuration.
Still delete temporary addresses, but don't add or update them.
(cherry picked from commit 1dbd9d7948)
When a ifcfg-rh connection becomes unamanaged it is removed from the
connection list in NMSettings and marked as removed; it is however
kept alive in the plugin and can become managed again later. To avoid
failed assertions, the @removed flag of the NMSettingsConnection must
be cleared if the connection is not being disposed.
(cherry picked from commit a9384452ed)
We set a dedicated route to reach the VPN gateway only if the parent
device has a gateway. If the parent device doesn't have a gateway (for
example in case of GSM connections) and the VPN gets the default
route, the VPN gateway will be contacted through the VPN itself, which
obviously doesn't work.
Set up a device route if the parent device doesn't provide a gateway.
https://bugzilla.redhat.com/show_bug.cgi?id=1403660
(cherry picked from commit ae5adc9e21)
This usually indicates that the driver missed beacons from the AP, due to driver bugs
or faulty power-save management. It doesn't mean that the PSK is wrong.
(cherry picked from commit 0c5aa6e48b)
- use nm_auto_close cleanup attribute
- optionally, return the found ifname
- don't stat "phy80211". If such an entity can be opened,
just assume it's a directory.
(cherry picked from commit 76876e896c)
Since function nmp_utils_open_sysctl() can avoid race condition, use it
in wifi_utils_is_wifi() to open sysfs and correctly check if it's a wifi
device.
https://bugzilla.gnome.org/show_bug.cgi?id=775613
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from commit b95556eb78)
A race condition may happen when NetworkManager opens sysfs and udev
renames interface name at the same time. Thomas Haller provides a new
function [1] which can avoid the race condition when opening sysfs.
This patch is a direct copy from [1].
[1] https://mail.gnome.org/archives/networkmanager-list/2016-December/msg00004.html
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
(cherry picked from commit 713c74f6e4)
If a connection is ACTIVATED and another one is ACTIVATING but there
is no global connectivity, we currently set the manager state to
CONNECTING and start a connectivity check to verify whether the
manager state can be promoted to CONNECTED_GLOBAL.
If this connectivity check fails, we shouldn't promote a CONNECTING
state to CONNECTED_SITE.
Fixes: 084da69a30
(cherry picked from commit 7375822c95)
The manager state is already computed every time an active connection
changes state, it is not necessary to call nm_manager_update_state()
also when the property is read.
Moreover, nm_manager_update_state() emits a "notify::state" signal
which causes a re-read of the property by the nm-exported-object,
resulting in a nested execution of nm_manager_update_state().
(cherry picked from commit 4cc45ee291)
Don't change the address order from configuration, but instead sort
addresses just before returning them to clients.
(cherry picked from commit 0a0bca9c7f)
Don't change the address order from configuration, but instead sort
addresses just before returning them to clients.
(cherry picked from commit 9609d4da1d)
When multiple address are assigned to an interface and the kernel must
decide which one should be used to communicate with a given IP, it
chooses the most specific one in the same subnet as the
destination. In case there are multiple addresses in the same subnet,
the primary address is choosen, which is basically the first one that
was added.
With commit 7197425137 ("device: expose NMIP4Config:addresses in
stable/defined sort order") we sorted all the addresses before
committing the configuration, with the side effect that the order no
longer respected the one in the user configuration.
Instead, change the sort function to keep the subnet order unchanged.
(cherry picked from commit e02752c2ed)
Since commit 9fafb382db, we would
explicitly set libnl's socket buffer size to 4*getpagesize().
That is also the default of libnl itself. Additionally, we would
workaround too small buffers by increasing the buffer size up to 512K.
A too small buffer causes messages to be lost. Usually, that only
results in a cache-resync, which isn't too bad. Lost messages are however
a problem if the lost message was an ACK that we were waiting for.
However, it is rather unlikely to happen, because it's expected that
the buffer size gets adjusted already when the cache is filled initially,
before any other requests are pending.
Still, let's increase the default buffer size to 32K, hoping that this
initial value is already large enough to avoid the problem altogether.
Note that iproute2 also uses a buffer size of 32K [1] [2].
Alternatively, we could use MSG_PEEK like systemd does [3]. However,
that requires two syscalls per message.
[1] https://patchwork.ozlabs.org/patch/592178/
[2] https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/tree/lib/libnetlink.c?id=f5f760b81250630da23a4021c30e802695be79d2#n274
[3] cd66af2274/src/libsystemd/sd-netlink/netlink-socket.c (L323)
(cherry picked from commit ed82b6bcb3)
Autoconnect property doesn't really matter for the applied
connection. Whitelist it from the properties and allow changing
it during reapply.
(cherry picked from commit d29839c430)
We don't want to enable MSG_PEEK due to the overhead. But when we detect
that we just lost a message due to MSG_TRUNC, increase the buffer size and
retry.
See-also: 55ea6e6b6c
(cherry picked from commit 9fafb382db)
Plugins could be already failed or disconnected when the helper fires.
E.g. they could send in an invalid IP4Config that would cause them to
fail and then follow with an IP6Config before they realize it's of no
use. We'd hit an assertion failure in that case, because the
NMVpnConnection would already be cleaned up.
(cherry picked from commit bf70ed2e86)
Otherwise its path remains visible on D-Bus despite the object is gone,
making libnm sad and grumpy:
libnm-WARNING **: no object known for /org/freedesktop/NetworkManager/AccessPoint/666
(cherry picked from commit d0c01cc79d)
When going to sleep, we unmanage devices setting the unmanaged flags
immediately but delaying the state transition (because we do it from
another state transition). The signal handler can be executed after
the wake and, especially, after we have already re-managed the device,
making the device unmanaged again.
Detect such situation and force the state to UNMANAGED (which will
also clear any pending state change), so that later we manage the
device again and it will try to activate any available connection.
Fixes: 81ea812362
(cherry picked from commit 3cc06c3db679c1ff2f61a301396393300d36adbb)
The interaction between the manager state and connectivity check code
is tricky. When there is an active connection with a default route and
NMConnectivity reports full connectivity, we set the CONNECTED_GLOBAL
state. However, if the connectivity check hasn't run yet, we stay in
CONNECTED_SITE state. If there are also other connections that are
activating, the state is set to CONNECTING.
This is a problem, because in CONNECTING we never run the connectivity
check and thus we fail to recognize that there is full connectivity
until a periodic check is run.
To solve this, schedule the connectivity check every time there is an
active connection with default route, even if other connection are
still activating, so that the check result can make the state progress
to CONNECTED_GLOBAL.
(cherry picked from commit 084da69a30)
For example for tun devices we get a lot of
(tun7): hw-addr: failed reading current MAC address
warnings. Just be silent about it. We log when something
changes, we don't need to log when we fail to obtain
a MAC address.
Thereby, refactor nm_device_update_hw_address() to return early.
(cherry picked from commit 0e0018c801)
Conflicts:
src/devices/nm-device.c
The unmanaged flags PLATFORM_INIT indicates whether UDEV is done
initializing the device. We should not handle IP config changes
before that pointer.
This avoids codepaths that require the permanent MAC address of the
device. We should not freeze the permanent MAC address before
UDEV initialized the device, for two reasons:
- getting the permanent MAC address using ethtool is racy as
UDEV might still rename the interface.
- freezing a fake permanent MAC address should only happen after
UDEV is done configuring the MAC address of software devices.
#0 0x000055555568bc7a in nm_device_update_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1) at src/devices/nm-device.c:11817
#1 0x000055555568c443 in nm_device_get_permanent_hw_address_full (self=self@entry=0x555555f0fb70 [NMDeviceVeth], force_freeze=force_freeze@entry=1, out_is_fake=out_is_fake@entry=0x0)
at src/devices/nm-device.c:12227
#2 0x000055555568cb06 in nm_device_get_permanent_hw_address (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:12237
#3 0x000055555568cb50 in spec_match_list (self=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12294
#4 0x00005555556a4ee6 in spec_match_list (device=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device-ethernet.c:1461
#5 0x00005555556978db in nm_device_spec_match_list (self=self@entry=0x555555f0fb70 [NMDeviceVeth], specs=0x555555a5c000 = {...}) at src/devices/nm-device.c:12277
#6 0x000055555558e187 in _match_section_infos_lookup (match_section_infos=0x555555a5d500, keyfile=0x555555a46f80, property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth], out_value=out_value@entry=0x7fffffffe018) at src/nm-config-data.c:1169
#7 0x00005555555922ca in nm_config_data_get_connection_default (self=0x555555a548c0 [NMConfigData], property=property@entry=0x555555793123 "ipv4.route-metric", device=device@entry=0x555555f0fb70 [NMDeviceVeth]) at src/nm-config-data.c:1234
#8 0x00005555556790cd in _get_ipx_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth], is_v4=is_v4@entry=1) at src/devices/nm-device.c:1142
#9 0x000055555567912e in nm_device_get_ip4_route_metric (self=self@entry=0x555555f0fb70 [NMDeviceVeth]) at src/devices/nm-device.c:1161
#10 0x000055555567da6c in ip4_config_merge_and_apply (self=self@entry=0x555555f0fb70 [NMDeviceVeth], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0)
at src/devices/nm-device.c:4787
#11 0x000055555567e0fb in update_ip4_config (self=self@entry=0x555555f0fb70 [NMDeviceVeth], initial=initial@entry=0) at src/devices/nm-device.c:9532
#12 0x0000555555693acd in queued_ip4_config_change (user_data=0x555555f0fb70) at src/devices/nm-device.c:9651
#13 0x00007ffff4c966ba in g_main_context_dispatch (context=0x555555a46af0) at gmain.c:3154
#14 0x00007ffff4c966ba in g_main_context_dispatch (context=context@entry=0x555555a46af0) at gmain.c:3769
#15 0x00007ffff4c96a70 in g_main_context_iterate (context=0x555555a46af0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#16 0x00007ffff4c96d92 in g_main_loop_run (loop=0x555555a47400) at gmain.c:4034
#17 0x000055555558372a in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:411
(cherry picked from commit 31ca7962f8)
Before the link is initialized, that is before UDEV completed
initializing the device, we should not evaluate the user-settings
unmanaged flags.
The reason is, that evaluating it likely involves looking at the
permanent MAC address, which might use the wrong fake MAC address
(before UDEV set the right one). Also, it might use the wrong ifname
to lookup the permanent MAC address via ethtool.
(cherry picked from commit c0d249b733)
The permanent MAC address of an NMDevice shall not change as
long as the device is realized. That is, we read it only once
and don't change it afterwards.
There are two issues that this commit tries to mitigate:
(1) users are advised to use UDEV to rename interfaces. As we lookup
the permenent MAC address using ethtool (which uses the interface
name), there is a race where we could read the permanent MAC
address using the wrong interface name. We should wait until
UDEV finished initializing the device and until the interface
name is stable (see rh#1388286).
This commit still cannot avoid the race of ethtool entirely. It only
tries to avoid ethtool until UDEV has done its work. That is, until we
expect the interface name no longer to change.
(2) some device types, don't have a permanent MAC address so we fall
back to use the currently set address (fake). Again, users are advised
to use UDEV to configure the MAC addresses on such software devices.
Thus, we should not get the fake MAC address until UDEV initialized
the device.
This patch actually doesn't solve the problem at all yet.
The reason is that a regular caller of nm_device_get_permanent_hw_address() can
not afford to wait until UDEV settled. Thus, any user who requests the
permanent MAC address before the link is initialized, runs into the
problems above.
In a next step, we shall revisit such calls to nm_device_get_permanent_hw_address()
and delay them until the link is initialized.
(cherry picked from commit 7b7c653c4f)
Conflicts:
src/devices/nm-device.c
src/nm-manager.c
We repeatedly call nm_device_update_hw_address() to reset the cached
MAC address of the device. However, we don't allow changing the address
length once it is set.
Multiple entities (initial, current and permanent MAC address) are all
checked to have the same address length. Changing the length would be a
very strange thing (and probably indicate a bug somewhere else).
Just don't allow that.
(cherry picked from commit cbea1f9f23)
Now that we persist the fake permanent address across
restart of NetworkManager, we want to consider fake
addresses as good enough in most cases.
(cherry picked from commit 416164aa29)
The default wired connection is already generated allowing the use of a fake
address, but for the state file and the device matching specs only non-fake
addresses are used. Let's allow fake addresses consistently, so that default
wired connections work properly in containers (where the veth address is
considered fake) as well.
Also, it would really be a better idea to use ifnames everywhere instead, but
that would change the format of the state file.
(cherry picked from commit bcb685c4cb)
_nm_utils_hwaddr_length() did a validation of the string
and returned the length of the address. In all cases where
we were interested in that, we also either want to validate
the address, get the address in binary form, or canonicalize
the address.
We can avoid these duplicate checks, by using _nm_utils_hwaddr_aton()
which both does the parsing and returning the length.
(cherry picked from commit e5fe5a4c03)
Since commit 1495853e01, LOGD_HW is renamed to
LOGD_PLATFORM. Remove the internal usage of the deprecated name.
Backport this patch to nm-1-4 because it avoids follow-up conflicts with
future backports. Also, it is a really trivial change, meaning, we only
replace the obsolte LOGD_HW name.
(cherry picked from commit 64951f07fb)
Conflicts:
src/devices/nm-device.c
src/devices/wwan/nm-modem.c
