Dracut documents the BOOTIF argument to be a MAC address and so we
accept one in any of the conventions we recognize. However, the PXE boot
loaders like to prepend a "01-" to denote an ethernet hardware type.
Accept that too.
https://bugzilla.redhat.com/show_bug.cgi?id=1726240
(cherry picked from commit 2952953a48)
Certain arguments (such as "nameserver") don't specify a connection they
apply to and using them would generate a default ethernet connection.
This is probably not the right thing to do.
(cherry picked from commit 6da2058237)
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)
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)
Use the 'x' conversion specifier for hexadecimal numbers.
Fixes: f53218ed7c ('cli: add property type for enum and showcase for ipv6.addr-gen-mode'):
(cherry picked from commit 420554a72e)
NMConnectivity can now distinguish between LIMITED and NONE connectivity
and it does so based on whether IP addresses and routes are configured.
Previously, NMConnectivity would not differenciate between limited and
no connectivity, which is why NMDevice added some additional logic on top
to coerce LIMITED to NONE (if the device is not logically connected).
But note that the connectivity state (whether a network is reachable on
an interface) depends on what is configured in kernel and whether the
internet is reachable on that interface. It does not depend on the
logical device state.
On the other hand, whether the device is configured in a manner to have
connectivity depends on the logical state of the device (as NetworkManager
is configuring the device).
So, in many cases, the logical state and the connectivity state agree now,
but for the right reasons.
This reverts commit 4c4dbcb78d.
(cherry picked from commit 5a416a9da1)
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)
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)
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)
If the mode is one of '802.3ad', 'tlb' or 'alb' and the connection has
both 'arp_interval' and 'arp_ip_target' options, during normalization
we remove 'arp_interval' because unsupported in the current mode. The
connection then becomes invalid because 'arp_ip_target' requires
'arp_interval'.
Since 'arp_interval' and 'arp_ip_target' are mutually dependent, the
latter should also be unsupported for those bonding modes.
https://bugzilla.redhat.com/show_bug.cgi?id=1718173
(cherry picked from commit fa0f87fef7)
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)
Also, plan right away to backport this symbol all the way back to
1.14.8. As such, we only need to add it once, with the right linker
version "libnm_1_14_8".
But still, the symbols first appears on a major release 1.20.0.
(cherry picked from commit a4c1489507)
This matters for properties that don't have 0/NULL/FALSE as
default value and when setting an empty property with
$ nmcli connection modify "$PROFILE" setting.property ''
Fixes: 3c82db710f ('cli: reset default value of properties via set_fcn()')
(cherry picked from commit 403f207fe5)
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)
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)
If we created a software interface it is because we already decided
that it should be managed, and so there is no point in waiting udev to
check that the interface is not udev-unmanaged.
We still wait udev for software interfaces created externally.
(cherry picked from commit 58db61545d)
An active connection started by user could be queued in state UNKNOWN
which means the device hasn't started activating yet. Eventually it
will, and we don't want to cancel the user activation because of an
internal autoconnection attempt.
(cherry picked from commit d33c995d45)
