At this point we don't know if the slave has been using an assumed
connection that just vanished -- the best bet is to let the device be.
If it's meant to be unenslaved, it won't be due to an external event.
https://bugzilla.redhat.com/show_bug.cgi?id=1357738
(cherry picked from commit 3127fb0d17)
When a software device unrealizes, we want to forget about the "user-explict"
unmanaged state. It means, that after a software device is deleted, the
"user-explict" managed flag will be cleared for that device.
It might be nice to preserve the managed-state after deletion of the device.
However, the unrealized-device only exists as long as we have a connection
for the device. That means, before this patch whether the unmanaged flag
was forgotten depends on whether the user had some connections that keep
the device alive as unrealized. That behavior was complicated, just don't
do that.
(cherry picked from commit 34880d62d0)
There is a "goto retry" in do_change_link_request(), at that point,
seq_result has the value -EOPNOTSUPP, instead of
WAIT_FOR_NL_RESPONSE_RESULT_UNKNOWN.
Fixes: 02fb3eff48
(cherry picked from commit 145d199589)
It seems some drivers return success for nm_platform_link_set_address(),
but at that point the address did not yet actually change *sigh*.
It changes a bit later, possibly after setting the device up.
Add a workaround to retry reading the MAC address when platform indicates
success but the address still differs at first.
https://bugzilla.gnome.org/show_bug.cgi?id=770456
(cherry picked from commit 67b6852358)
Seems odd numbers may be coerced to the next-smaller even number.
Avoid that by using an even number for the test, as the number
has no particular meaning.
https://bugzilla.gnome.org/show_bug.cgi?id=765835
(cherry picked from commit 895c61a742)
Depending on the connection we are about to read,
we would assert that the user provided a @out_unhandled
argument.
That means, the user must always provide a valid @out_unhandled
pointer, because he cannot know beforehand how the reading
of the ifcfg file goes.
(cherry picked from commit 50d7ac4af3)
Clear some IP related entries from the ifcfg-rh file if
the connection is a slave connection.
Also, drop utils_ignore_ip_config(). It is guaranteed, that
writer only handles connections that verify(). Such connections
have an IPv4/IPv6 setting if (and only if) they are not slave
types.
https://bugzilla.redhat.com/show_bug.cgi?id=1368761
(cherry picked from commit cf7b8866ce)
A user may very well have connections on disk with bogus json.
Such connections may have failed to activate before, but rejecting
them now as invalid means that we stop loading them from disk. That is,
they disappear after upgrade.
Instead of doing that, also accept invalid json (beside "") and
normalize/coerce it to NULL.
https://bugzilla.redhat.com/show_bug.cgi?id=1366300
(cherry picked from commit 476810c290)
Commit 4c7fa8dfdc ("core: drop root requirement for
load_connection(s)/set_logging D-Bus calls") removed the enforcing of
permission in the daemon for such methods since the D-Bus daemon
configuration already does that. That change also allows clients to
send a request and not wait for a response, since we don't have to
check the caller credentials in the daemon.
In the future we might switch to polkit for these methods, breaking
clients that don't wait for a reponse, so it seems better to prevent
from beginning such behavior.
Fixes: 4c7fa8dfdc
(cherry picked from commit dd27b79c4e)
The VPN data comes from an external source, it may be bogus.
Default-routes are not allowed on this point and would trigger
an assertion afterwards. Skip over them.
(cherry picked from commit 071103b172)
We need an ifindex for the NMIP4Config/NMIP6Config instance.
For interface-less VPN types, we need to lookup the parent
device, as already done for IPv4.
Fix IPv6 case too.
https://bugzilla.redhat.com/show_bug.cgi?id=1368354
(cherry picked from commit 2da35ddfe8)
When activating a connection, it may fail with nmcli reporting:
$ nmcli connection up id "Wired Connection 1"
Error: Connection activation failed: Active connection removed before it was initialized
This should be easily reproducible by having a connection "Wired Connection 1" with
cloned-mac-address set to random. When the connection is already active on a device,
re-activating with
$ nmcli connection up id "Wired Connection 1"
fails.
We first create a queued-activation and tear down the existing
connection:
device (enp0s25): state change: deactivating -> disconnected (reason 'new-activation')
Shortly after we see:
device[0x557d02cdb0c0] (enp0s25): set-hw-addr: setting MAC address to 'AA:BB:CC:DD:EE:FF' (reset, deactivate)...
device[0x557d02cdb0c0] (enp0s25): taking down device
later, we get:
device (enp0s25): link disconnected
device[0x557d02cdb0c0] (enp0s25): queued state change to unavailable due to carrier-changed (id 17290)
in the meantime, the queued activation request starts:
device (enp0s25): Activation: starting connection 'my-wired' (ca058ec5-8a47-4e1e-b38e-962b71c4699e)
but the device already transitions to unavailable
device[0x557d02cdb0c0] (enp0s25): running queued state change to unavailable (id 17290)
device (enp0s25): state change: disconnected -> unavailable (reason 'carrier-changed') [30 20 40]
which kills the new activation request:
active-connection[0x557d02c10e40]: set state deactivated (was unknown)
Just delay a carrier-lost handling if we have any queued activation
requests.
(cherry picked from commit d4e9b30320)
These logging lines are already disabled by default as _LOGt()
is a NOP unless configured --with-more-logging.
However, the logging is still very verbose also for debug-builds
and currently there are no known issues there. Disable the logging
statements (but leave them in so they can easily be enabled).
(cherry picked from commit 4cb845558e)
The error returned to users when a load_connection(s)/set_logging call
fails due to D-Bus policy denial is a bit obscure:
$ nmcli general logging level debug
Error: failed to set logging: Rejected send message, 4 matched rules;
type="method_call", sender=":1.233" (uid=1001 pid=27225 comm="nmcli
general logging level debug ")
interface="org.freedesktop.NetworkManager" member="SetLogging" error
name="(unset)" requested_reply="0" destination=":1.207" (uid=0
pid=25793 comm="/usr/sbin/NetworkManager --no-daemon ")
Convert it to a more comprehensible:
$ nmcli general logging level debug
Error: failed to set logging: access denied
https://bugzilla.redhat.com/show_bug.cgi?id=1362542
(cherry picked from commit 805925f9ef)
The D-Bus configuration already ensures that only root can do that;
enforcing the permission at policy level seems better than doing it in
the daemon itself because it allows users to change the policy and
also because callers can exit immediately after issuing the request.
(cherry picked from commit 4c7fa8dfdc)
When a assumed software device is brought down externally, it becomes
UNMANAGED_EXTERNAL_DOWN and its state goes from ACTIVATED directly to
UNMANAGED. In such case, we shouldn't flush the IP configuration
(addresses and routes) present on the device.
To fix this, clean up the device with CLEANUP_TYPE_KEEP and modify
nm_device_cleanup() not to flush addresses and devices with such flag.
https://bugzilla.redhat.com/show_bug.cgi?id=1363995
(cherry picked from commit 45cd3302dc)
Previously, we logged also the location (file:line func). nm-logging.c
supported format flags to control the timestamp, the location, and alignment
of the timestamp.
We want that all our logging backends log the same messages. That is,
both syslog and journal should have our ~default~ logging format, that
is with timestamp but without location.
Drop the unused code.
(cherry picked from commit cc828431b8)
Even if we know that the new hostname being set is equal to the cached
old one, the user may have manually changed the kernel hostname in the
meanwhile. For example:
# hostname
host123
# hostname localhost
# nmcli connection up eth1
# (now NM receives 'host123' from DHCP, but
# believes it's already set and doesn't update it)
# hostname
localhost
Let's always try to update the kernel (transient) hostname, unless it
is really already set (as returned by gethostname()).
https://bugzilla.redhat.com/show_bug.cgi?id=1356015
(cherry picked from commit 51b2cef04f)
