If the @append_force argument is set and the object is already in the
list, it must be moved at the end.
Fixes: 22edeb5b69 ('core: track addresses for NMIP4Config/NMIP6Config via NMDedupMultiIndex')
(cherry picked from commit 8b121c7048)
(cherry picked from commit 52241748e8)
(cherry picked from commit d6c3d9c9dc)
Add test to show a wrong result of ip_ipX_config_replace() due to a
bug in _nm_ip_config_add_obj(). When an address is added to the tail
of the index and another address with the same id already exists, the
existing object is left at the same place, breaking the order of
addresses.
(cherry picked from commit 24741bff8b)
(cherry picked from commit ebaf890057)
(cherry picked from commit eb56d48c0b)
Fixes: 1ae5d53354 ('bluez: add support for BlueZ 5')
(cherry picked from commit 25571bb639)
(cherry picked from commit 6118f808d9)
(cherry picked from commit b629570a75)
Fixes: 9b935fad9b ('modem: don't use GAsyncResult pattern for disconnecting modem')
(cherry picked from commit 22cd9e754b)
(cherry picked from commit 47c772354e)
(cherry picked from commit 05319cb391)
Not all masters type have a platform link and so it's wrong to check
for it to decide whether the slave should be really released. Move the
check to master devices that need it (bond, bridge and team).
OVS ports don't need the check because they don't call to platform to
remove a slave.
https://bugzilla.redhat.com/show_bug.cgi?id=1733709
(cherry picked from commit 57e3734b6c)
(cherry picked from commit ec1b5fb019)
(cherry picked from commit f6a90b899a)
We set nm-owned to indicate whether a software device was created by
NM or it was pre-existing. When checking the existence, we must verify
also whether the link type is compatible with the device, otherwise it
is possible to match unrelated interfaces. For example, when checking
for the existence of an ovs-bridge (which is not compatible with any
platform link) we could match a unrelated platform link with the same
name.
https://bugzilla.redhat.com/show_bug.cgi?id=1733709
(cherry picked from commit 3cb4b36261)
(cherry picked from commit cb20d0791a)
(cherry picked from commit 511ef27d5e)
4 properties are not really relevant for an already activated connection
or it makes not sense to change them. These are connection.id, connection.uuid,
connection.autoconnect and connection.stable-id.
For convenience, we allow to reapply these. This way, one can take
a different setting (e.g. with a different connection.id or
connection.uuid) and reapply them, but such changes are silently
ignored.
However this was done wrongly. Instead of reverting the change to the new
applied connection, we would change the input connection.
This is bad, for example with
nmcli connection up uuid cb922f18-e99a-49c6-b200-1678b5070a82
nmcli connection modify cb922f18-e99a-49c6-b200-1678b5070a82 con-name "bogus"
nmcli device reapply eth0
the last re-apply would reset the settings-connection's connection ID to
what was before, while accepting the new name on the applied-connection
(while it should have been rejected).
Fixes: bf3b3d444c ('device: avoid changing immutable properties during reapply')
(cherry picked from commit adb51c2a7f)
(cherry picked from commit 09f37d5bd4)
NMDevicePPP only handles connections with the pppoe.parent property
set. match_connection() already checks this when we creating a new
device. We should also perform the same check in
check_connection_compatible().
Fixes: 6c3195931e ('core: implement activation of PPP devices')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/203
(cherry picked from commit 17f4a1e794)
(cherry picked from commit 5ca888d693)
The platform is used to detect whether to skip the connectivity check right away.
It should be an optional argument, so one could avoid this pre-check.
(cherry picked from commit b626baa313)
(cherry picked from commit a842280dbe)
If the interface has no carrier, no addresses or no routes there is no
point in starting a connectivity check on it because it will fail.
Moreover, doing the check on a device without routes causes the
addition of a negative entry in the ARP table for each of the
addresses associated with the connectivity check host; this can lead
to poor network performances.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/181
(cherry picked from commit 91d447df19)
(cherry picked from commit 7f937ecece)
pppd restores the previous settings for the serial port it uses right
before exiting. It is especially important to do so because otherwise
ModemManager is not able to recover the port as it can receive a hangup
event from the port due to CLOCAL not being restored. However, there is
currently a race condition that produces this issue. This is because
when PHASE_DEAD is notified, pppd still has not restored the port
settings - it does that a bit later, in the die() function.
This patch delays notifying PHASE_DEAD until when the exitnotify() hook
is called by pppd: when this happens the port settings have already been
restored.
There were previously efforts to fix this in commit fe090c34b7, so
PHASE_DEAD was used instead of PHASE_DISCONNECT to notify MM that the
port was disconnected, but that still early to ensure that the port
settings are restored.
The MM traces seen when the bug is triggered are:
ModemManager[2158]: <warn> (ttyACM1): could not re-acquire serial port lock: (5) Input/output error
ModemManager[2158]: <warn> Couldn't load Operator Code: 'Cannot run sequence: 'Could not open serial device ttyACM1: it has been forced close'
https://mail.gnome.org/archives/networkmanager-list/2019-June/msg00014.html
(cherry picked from commit a251712a72)
(cherry picked from commit 3caa065709)
The values cached in the device may be stale when we start a new
activation because in a disconnected state we might have called
ip_config_merge_and_apply() which cached the main table value.
(cherry picked from commit 5be69ba794)
(cherry picked from commit 14cfffa64c)
Before commit e3ac45c026 the reader set the private key in the
setting using the libnm function, which also set the key as client
certificate if it was in PKCS #12 format.
After the commit, existing connections with a PKCS #12 private key but
without a client certificate became invalid. Restore the old behavior.
Fixes: e3ac45c026 ('ifcfg-rh: don't use 802-1x certifcate setter functions')
(cherry picked from commit 9a410fc312)
(cherry picked from commit 51896e1e6b)
The writer should only persist properties without too much additional
logic, which should be instead embedded in the setting itself.
(cherry picked from commit a995244e9b)
(cherry picked from commit 5a5cd8d05d)
This will be the default for Slackware 15.0 and on.
This should be safe for both master and 1.12.x stable branch, as
no existing Slackware releases are expected to run NM-1.12.x or
later.
Signed-off-by: Robby Workman <rworkman@slackware.com>
https://mail.gnome.org/archives/networkmanager-list/2019-May/msg00011.html
(cherry picked from commit e1df17e0ac)
(cherry picked from commit 065e810424)
Ooherwise, the file has wrong permissions:
# ls -la /var/lib/NetworkManager/secret_key
----r-xr-x. 1 root root 50 May 14 13:52 /var/lib/NetworkManager/secret_key
Luckily, /var/lib/NetworkManager should be already
# ls -lad /var/lib/NetworkManager
drwx------. 2 root root 8192 May 14 13:57 /var/lib/NetworkManager
which mitigates this a bit.
Fixes: dbcb1d6d97 ('core: let nm_utils_secret_key_read() handle failures internally')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/175
(cherry picked from commit dc3a2f9bc4)
(cherry picked from commit 2d46247c6a)
The boolean value is intended to indicate success. It would indicated
failure due to a bug.
Fixes: 297d4985ab ('core/dbus: rework D-Bus implementation to use lower layer GDBusConnection API'):
(cherry picked from commit 22e830f046)
(cherry picked from commit e73a505866)
If the link is down we shouldn't drop the link-local address from
configuration as it wasn't removed by user but by kernel.
(cherry picked from commit 18d2edfaa1)
(cherry picked from commit 6f69144500)
Consider the situation in which ipv4.method=auto and there is an
address configured. Also, the DHCP timeout is long and there is no
DHCP server. If the link is brought down temporarily, the prefix route
for the static address is lost and not restored by NM because we
reapply the IP configuration only when the IP state is DONE.
The same can happen also for IPv6, but in that case also static IPv6
addresses are lost.
We should always reapply the IP configuration when the link goes up.
(cherry picked from commit d0b16b9283)
(cherry picked from commit 4482ca64ba)
When we set the MTU on the link we remember its previous source
(ip-config, parent-device or connection profile) and don't change it
again afterwards to avoid interfering with user's manual changes. The
only exceptions when we change it again are (1) if the parent device
MTU changes and (2) if the new MTU has higher priority than the one
previously set.
To allow a live reapply of the MTU property we also need to clear the
saved source, or the checks described above will prevent setting the
new value.
Fixes: 2f8917237f ('device: rework mtu priority handling')
https://bugzilla.redhat.com/show_bug.cgi?id=1702657
(cherry picked from commit 4ed72fa658)
(cherry picked from commit e738479bdd)
Fix the following assertion failure:
g_object_ref: assertion 'G_IS_OBJECT (object)' failed.
nm_settings_add_connection() can return a NULL connection.
Fixes: f034f17ff6 ('settings: keep the added connection alive for a bit longer')
(cherry picked from commit 48ce3628c5)
(cherry picked from commit d80818e6ca)
Why didn't we get a compiler warning about this bug?
At least clang (3.8.0-2ubuntu4, Ubuntu 16.04) warns:
CC src/platform/src_libNetworkManagerBase_la-nm-platform.lo
../src/platform/nm-platform.c:5389:14: error: data argument not used by format string [-Werror,-Wformat-extra-args]
lnk->remote ? nm_sprintf_buf (str_remote, " remote %s", nm_utils_inet4_ntop (lnk->remote, str_remote1)) : "",
^
Fixes: 4c2862b958 ('platform: add gretap tunnels support')
(cherry picked from commit dfb899f465)
(cherry picked from commit ed88c71f15)
If NM fails to connect to teamd, it currently just sets the device
state to FAILED and waits that deactivate() is called later. However,
the 5 seconds timeout on teamd process start can hit in the meantime,
which fails with an assertion "nm_device_is_activating (device)".
Clean up the device state when the connection to teamd fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1697900
(cherry picked from commit c48698d747)
Go straight to unmanaged. That's what all the other devices do when
their backing resources vanish. If the device reached disconnected
state, an autoconnect check would try to connect it back, in vain.
https://github.com/NetworkManager/NetworkManager/pull/324
(cherry picked from commit 045b88a5b5)
Open vSwitch is the special kid on the block -- it likes to be in charge of
the link lifetime and so we shouldn't be. This means that we shouldn't be
attempting to remove the link: we'd just (gracefully) fail anyways.
More importantly, this also means that we shouldn't care if we see the link
go away. Once the device reaches DISCONNECTED state, its configuration is
cleaned up and we may already be activating another connection. We shouldn't
alter the device state when OpenVSwitch decides to drop the old link.
https://bugzilla.redhat.com/show_bug.cgi?id=1543557https://github.com/NetworkManager/NetworkManager/pull/324
(cherry picked from commit 3a55ec63e1)
Fixes a crash on failed AddAndActivate:
$ ip link set eth0 down
$ nmcli d conn eth0
Error: Failed to add/activate new connection: Connection 'eth0' is not available on device eth0 because device has no carrier
<NetworkManager crashes>
#3 0x000055555558b6c5 in _nm_g_return_if_fail_warning
#4 0x00005555557008c7 in nm_settings_has_connection
#5 0x0000555555700e5f in pk_add_cb
#6 0x0000555555726e30 in pk_call_cb
#7 0x0000555555726e30 in pk_call_cb
#8 0x0000555555726e30 in pk_call_cb
#9 0x00005555555aaea8 in _call_id_invoke_callback
#10 0x00005555555ab2e8 in _call_on_idle
https://github.com/NetworkManager/NetworkManager/pull/325
(cherry picked from commit f034f17ff6)
If we surprise-remove the master, slaves would immediately attempt to bring
things up by autoconnecting. Not cool. Policy, however, blocks
autoconnect if the slaves disconnect due to "dependency-failed", and it
indeed seems to be an appropriate reason here:
$ nmcli c add type bridge
$ nmcli c add type dummy ifname dummy0 master bridge autoconnect yes
$ nmcli c del bridge
$
Before:
(nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
(nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
(nm-bridge): detached bridge port dummy0
(dummy0): state change: activated -> disconnected (reason 'connection-removed')
(nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
(dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
policy: auto-activating connection 'bridge-slave-dummy0'
After:
(nm-bridge): state change: ip-config -> deactivating (reason 'connection-removed')
(nm-bridge): state change: deactivating -> disconnected (reason 'connection-removed')
(nm-bridge): detached bridge port dummy0
(dummy0): state change: activated -> deactivating (reason 'dependency-failed')
(nm-bridge): state change: disconnected -> unmanaged (reason 'user-requested')
(dummy0): state change: deactivating -> disconnected (reason 'dependency-failed')
(dummy0): state change: disconnected -> unmanaged (reason 'user-requested')
https://github.com/NetworkManager/NetworkManager/pull/319
(cherry picked from commit 8f2a8a52f0)
