Instead of throwing an assertion, fail DHCPv6 when a IPv6 link-local
address is not configured on the device. There are different reasons
why the assertion may fail: for example the address was removed
externally; or the device is gone (and thus the platform already
received the notification of addresses removal) but the device is still
connecting because its disposal happens in an idle callback.
None of these deserves an assertion, which should only be for
programming errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1432251
(cherry picked from commit 4987ec408a)
(cherry picked from commit 238fc87298)
This makes it more likely that the user will end up with a master
connection that has connection.interface-name property. This makes it
possible for ifcfg plugin to specify the master in the for of device
name (as opposed to UUID) for compatibility with the legacy network
tooling.
This is equivalent to what nmcli does.
https://bugzilla.redhat.com/show_bug.cgi?id=1369091
(cherry picked from commit ff46158d9e)
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 some point gobject-introspection added an API to add a library path
and stopped honoring the LD_LIBRARY_PATH (a bug, according to GI
documentation?).
(cherry picked from commit 6c96aafaa9)
(cherry picked from commit 2ee8462774)
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)
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 as "NEVER" -- which due to
normalization also results in cloned-mac-address=permanent.
(cherry picked from commit 46d53e1101)
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)
Previously, due to a bug in "tools/enums-to-docbook.pl", enum values
without explicit numeric value were wrongly parsed. That is fixed,
but still explicitly set the value in the public header.
(cherry picked from commit 9d2207b46d)
Previously, an enum that didn't explicitly specify a numeric value
would wrongly start counting at 1.
E.g.
typedef enum {
MY_VAL,
} Name;
would result in documentation with MY_VAL=1.
https://bugzilla.gnome.org/show_bug.cgi?id=776848
(cherry picked from commit 36ec46e8f8)
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)
We already have gs_fd_close, which however doesn't preserve
errno and only checks for fd != -1. Add our own define.
Downside is, we have to include stdio.h and errno.h,
which effectively ends up to be included *everywhere*.
(cherry picked from commit 312cea870d)
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)
