For dynamic IP methods (DHCP, IPv4LL, WWAN) the route metric is set at
activation/renewal time using the value from static configuration. To
support runtime change we need to update the dynamic configuration in
place and tell the DHCP client the new value to use for future
renewals.
https://bugzilla.redhat.com/show_bug.cgi?id=1528071
(cherry picked from commit b9e6433a02)
When unplugging an USB 3G modem device, pppd does not exit correctly and
we have the following traces:
Sep 10 07:58:24.616465 ModemManager[1158]: <info> (tty/ttyUSB0): released by device '/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1'
Sep 10 07:58:24.620314 pppd[2292]: Modem hangup
Sep 10 07:58:24.621368 ModemManager[1158]: <info> (tty/ttyUSB1): released by device '/sys/devices/pci0000:00/0000:00:1c.0/0000:01:00.0/usb4/4-1'
Sep 10 07:58:24.621835 ModemManager[1158]: <warn> (ttyUSB1): could not re-acquire serial port lock: (5) Input/output error
Sep 10 07:58:24.621358 NetworkManager[1871]: <debug> ppp-manager: set-ifindex 4
Sep 10 07:58:24.621369 NetworkManager[1871]: <warn> ppp-manager: can't change the ifindex from 4 to 4
Sep 10 07:58:24.623982 NetworkManager[1871]: <info> device (ttyUSB0): state change: activated -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Sep 10 07:58:24.624411 NetworkManager[1871]: <debug> kill child process 'pppd' (2292): wait for process to terminate after sending SIGTERM (15) (send SIGKILL in 1500 milliseconds)...
Sep 10 07:58:24.624440 NetworkManager[1871]: <debug> modem-broadband[ttyUSB0]: notifying ModemManager about the modem disconnection
Sep 10 07:58:24.626591 NetworkManager[1871]: <debug> modem-broadband[ttyUSB0]: notifying ModemManager about the modem disconnection
Sep 10 07:58:24.681016 NetworkManager[1871]: <warn> modem-broadband[ttyUSB0]: failed to disconnect modem: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.freedesktop.ModemManager1.Modem.Simple' on object at path /org/freedesktop/ModemManager1/Modem/0
Sep 10 07:58:26.126817 NetworkManager[1871]: <debug> kill child process 'pppd' (2292): process not terminated after 1502368 usec. Sending SIGKILL signal
Sep 10 07:58:26.128121 NetworkManager[1871]: <info> device (ppp0): state change: disconnected -> unmanaged (reason 'unmanaged', sys-iface-state: 'removed')
Sep 10 07:58:26.135571 NetworkManager[1871]: <debug> kill child process 'pppd' (2292): terminated by signal 9 (1511158 usec elapsed)
This is due to nm-ppp-plugin waiting on SetIfIndex call until timeout,
which is longer than termination process timeout.
Calling g_dbus_method_invocation_return_value() on error fixes this.
Fixes: dd98ada33fhttps://mail.gnome.org/archives/networkmanager-list/2018-September/msg00010.html
(cherry picked from commit e66e4d0e71)
(cherry picked from commit b3ca8abe38)
When NM has to rebuild the platform cache, it first generates ADD and
then REMOVE events for the links. So, if an interface is removed and
readded, platform will emit the ADDED event with a new ifindex while
the device with old ifindex still exists.
In such case the manager currently updates the device's ifindex but
this causes problems as the DNS manager tracks configurations by their
ifindex and so the configurations for the old device will become
stale.
Fix this by removing the device and adding it again when we detect a
change of ifindex on a device that already had valid one.
https://bugzilla.redhat.com/show_bug.cgi?id=1542366
(cherry picked from commit 281974b932)
If the device is later realized again, we assert that there aren't any
IP config changes queued. Therefore, they must be cleared on
unrealize().
(cherry picked from commit 9ed07fbb46)
gboolean is a typedef for "int".
While older compilers might treat such bitfields as unsigned ([1]),
commonly such a bitfield is signed and can only contain the values 0
and -1.
We only want to use numeric 1 for TRUE, hence, creating such bitfields
is wrong, or at least error prone.
In fact, in this case it's a bug, because later we compare
it with a regular gboolean
if (priv->scanning != new_scanning)
[1] https://lgtm.com/rules/1506024027114/
Fixes: e0f9677018
(cherry picked from commit 610ca87016)
We don't want the users to default to running the code paths in tests that
we didn't check before. They may end up failing randomly.
(cherry picked from commit 9c6ff7fe18)
Master added the generated header "config-extra.h".
That file does not exist on this branch, so when
switching branches, this file shows up as untracked.
Just let git ignore it.
It seems, curl_multi_socket_action() can fail with
connectivity check failed: 4
where "4" means CURLM_INTERNAL_ERROR.
When that happens, it also seems that the file descriptor may still have data
to read, so the glib IO callback _con_curl_socketevent_cb() will be called in
an endless loop. Thereby, keeping the CPU busy with doing nothing (useful).
Workaround by disabling polling on the file descriptor when something
goes wrong.
Note that optimally we would cancel the affected connectivity-check
right away. However, due to the design of libcurl's API, from within
_con_curl_socketevent_cb() we don't know which connectivity-checks
are affected by a failure on this file descriptor. So, all we can do
is avoid polling on the (possibly) broken file descriptor. Note that
we anyway always schedule a timeout of last resort for each check. Even
if something goes very wrong, we will fail the check within 15 seconds.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903996
(cherry picked from commit 884a28b28c)
On non-Windows, libcurl's "curl_socket_t" type is just a typedef for
int. We rely on that, because we use it as file descriptor.
Add a compile time check to ensure that.
(cherry picked from commit 970af59731)
Since this is "C" there are not namespaces and libraries commonly choose
a particular name prefix for their symbols.
In case of libcurl, that is "curl_".
We should avoid using the same name prefix, and choose something distinct.
(cherry picked from commit a24f118a1f)
$ nmcli c add type ovs-port ifname ovsport0
Error: Failed to add 'ovs-port-ovsport0' connection: connection.type:
Only 'ovs-port' connections can be enslaved to 'ovs-bridge'
nm_streq0() is not good here. It fails (with a wrong error message) even
when the slave_type is not set, which it shouldn't since slave_type can
be normalized. The real problem is the lack of the master property.
This fixes the condition:
$ nmcli c add type ovs-port ifname ovsport0
Error: Failed to add 'ovs-port-ovsport0' connection: connection.master:
A connection with a 'ovs-port' setting must have a master.
Corrects the error message:
$ nmcli c add con-name br0 type bridge
$ nmcli c add type ovs-port ifname ovsport0 parent br0
Error: Failed to add 'bridge-slave-ovsport0' connection: connection.slave-type:
'ovs-port' connections must be enslaved to 'ovs-bridge', not 'bridge'
And gets rid of a confusing nm_streq0 use when comparing the type, since
at that point type must not be NULL anymore.
Fixes: 4199c976da
(cherry picked from commit 354140e8d3)
We previously kept any acd-manager running if the device was
disconnected. It was possible to trigger a crash by setting a long
dad-timeout and interrupting the activation request:
nmcli con add type ethernet ifname eth0 con-name eth0+ ip4 1.2.3.4/32
nmcli con mod eth0+ ipv4.dad-timeout 10000
nmcli -w 2 con up eth0+
nmcli con down eth0+
After this, the n-acd timer would fire after 10 seconds and try to
disconnect an already disconnected device, throwing the assertion:
NetworkManager:ERROR:src/devices/nm-device.c:9845:
activate_stage5_ip4_config_result: assertion failed: (req)
Fixes: 28f6e8b4d2
(cherry picked from commit 260cded3d6)
Such failures during connectivity checks, may happen frequently
and due to external causes. Don't log with error level to avoid
spamming the logfile.
(cherry picked from commit ca9981eb5d)
Commit 10753c3616 ("manager: merge VPN handling into
_new_active_connection()") added a check to fail the activation of
VPNs when a device is passed to ActivateConnection(), since the device
argument is ignored for VPNs.
This broke activating VPNs from nm-applet as nm-applet sets both the
specific_object (parent-connection) and device arguments in the
activation request.
Note that we already check in _new_active_connection() that when a
device is supplied, it matches the device of the parent
connection. Therefore, the check can be dropped.
Reported-by: Michael Biebl <biebl@debian.org>
Fixes: 10753c3616https://github.com/NetworkManager/NetworkManager/pull/159
(cherry picked from commit e205664ba8)
The @connection argument can be NULL; add the (allow-none) annotation
otherwise calling the API with a NULL argument through GObject
introspection fails with:
Argument 1 does not allow None as a value
Fixes: 278fd4fb0f
(cherry picked from commit f396826466)
