After 1.4.0 is released, merge it back into master so that
1.4.0 is part of the history of master. That means,
$ git log --first-parent master
will also traverse 1.4.0 and 1.4.0-rc1.
Also, the closest branch parent of master and nm-1-4 branch
becomes 1.4.0 tag.
Also bump the micro version to 1.5.1-dev to indicate that this is
after 1.4.0 is out, otherwise `git describe` uses the 1.4.0 tag.
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)
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
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)
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
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)
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.
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
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)
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.
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)
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).
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)
