We cannot abort the construction of a GLib object instance
like we did for NMDeviceWifi and NMDeviceOlpcMesh when
nm_platform_wifi_get_capabilities() failed.
Instead, check the capabilities first (in the factory method)
and only create the object instance when the device can be handled.
https://bugzilla.gnome.org/show_bug.cgi?id=760154
(cherry picked from commit 044de4cea2)
Objects that register to a signal of a singleton should own a reference
to the singleton to ensure the proper lifetime of the singleton upon shutdown.
(cherry picked from commit e2e22eb574)
If @ip_ifindex is zero, the IP interface has disappeared and
there's no point in updating @ip_iface.
Actually, unconditionally updating @ip_iface is dangerous because it
breaks the assumption used by other functions (as
nm_device_get_ip_ifindex()) that a non-NULL @ip_iface implies a valid
@ip_ifindex. This was causing the scary failure:
devices/nm-device.c:666:get_ip_iface_identifier: assertion failed: (ifindex)
https://bugzilla.redhat.com/show_bug.cgi?id=1268617
(cherry picked from commit ed536998f9)
Set @ppp_watch_id to zero upon pppd termination, otherwise the call to
g_source_remove(priv->ppp_watch_id) in dispose() could trigger a failed
assertion.
(cherry picked from commit 5f93f01015)
Parent MAC can be NULL if the interface has gone, fix the following
failed assertion:
[devices/nm-device-vlan.c:107] parent_hwaddr_changed(): (vlan1): parent hardware address changed
nm_device_set_hw_addr: assertion 'addr != NULL' failed
While at it, improve logging by printing the new MAC address.
Fixes: e6d7fee5a6
(cherry picked from commit e1d06d7a0b)
Allow calling nm_connection_get_virtual_iface_name() on a non-verified
connection by not asserting asserting against a valid base-setting.
On nma-1-0 branch, nm-applet can crash with:
#3 0x00007ffff2993a7a in g_assertion_message_expr (domain=0x7ffff51fad86 "libnm-util", file=0x7ffff51fb728 "nm-connection.c", line=320, func=0x7ffff51fc028 "_get_type_setting", expr=<optimized out>) at gtestutils.c:2444
#4 0x00007ffff51ac52f in _get_type_setting (connection=0xa3c160 [NMRemoteConnection]) at nm-connection.c:320
#5 0x00007ffff51ac341 in nm_connection_get_virtual_iface_name (connection=0xa3c160 [NMRemoteConnection]) at nm-connection.c:1436
#6 0x0000000000415bdc in add_virtual_items (type=type@entry=0x43c11d "bridge", all_devices=all_devices@entry=0x7f6580, all_connections=all_connections@entry=0x9354a0, menu=menu@entry=0x922990 [GtkMenu], applet=applet@entry=0x6cc000 [NMApplet]) at applet.c:1640
#7 0x00000000004176f6 in nma_menu_add_devices (menu=menu@entry=0x922990 [GtkMenu], applet=applet@entry=0x6cc000 [NMApplet]) at applet.c:1713
#8 0x0000000000418315 in nma_menu_show_cb (menu=0x922990 [GtkMenu], applet=0x6cc000 [NMApplet]) at applet.c:1974
where the connection type is "tun".
Note that libnm accepts invalid connections and exposes them to the
user (albeit issuing a warning). Later on there are many places where
that can lead to further g_return*(), which is ugly indeed.
At least, we should not assert against valid connections (because that
crashes the user) and there is a well known fact that the base setting
will be missing for tun settings. No need to even warn about that in
nm_connection_get_virtual_iface_name() (we already got the warning
during replace_settings).
(cherry picked from commit 8c27a370ff)
Fixes a crash if we can't read the ATM index. We need the ATM
index, and we can't do anything with the device before we have it,
so don't bother creating one if we we can't get it.
NetworkManager[9662]: <error> [1449678770.705541] [nm-device-adsl.c:607] constructor(): (atmtcp0): error reading ATM device index
(NetworkManager:9662): GLib-GObject-CRITICAL **: object NMDeviceAdsl 0x1e8f880 finalized while still in-construction
(NetworkManager:9662): GLib-GObject-CRITICAL **: Custom constructor for class NMDeviceAdsl returned NULL (which is invalid). Please use GInitable instead.
**
NetworkManager-adsl:ERROR:nm-atm-manager.c:121:adsl_add: assertion failed: (device)
(cherry picked from commit 9bb96b00a5)
At some point the platform changed to no longer ask the kernel for
interfaces when one wasn't in its cache, but to wait for netlink
events to be notified of the new interface. That broke some assumptions
that the ADSL code was making, causing a crash.
Rework the ADSL br2684 interface to clean up a couple of things
(get rid of 'disposed', consolidate dispose/deactivate cleanup) and
watch for the br2684 interface to show up with a periodic timeout.
(cherry picked from commit 29f4de09a5)
G_DEFINE_QUARK is only available since 2.34, include
"nm-glib-compat.h" to fix the following error:
./../common/nm-vpn-helpers.c: In function ‘G_DEFINE_QUARK’:
./../common/nm-vpn-helpers.c:54:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘{’ token
Fixes: dca2ded7e8
It allows nmcli and nmtui to ask for VPN passwords and thus successfully
activate VPN connections.
There is a special handling for OpenConnect, because the user does not know
the secrets. They have to be obtained by authenticating to OpenConnect server.
https://bugzilla.redhat.com/show_bug.cgi?id=975185
OpenConnect needs three secrets - COOKIE, HOST and FINGERPRINT. They can be
obtained by authenticating to the server. This can be performed by running
"openconnect --authenticate <host>" and the three values are printed to stdout.
Note that the function may (probably will) interactively ask user for
his credentials.
Alternatively, it would be possible to dlopen() libopenconnect and call its
functions. However, as that would be more complicated and would also require
implementing functionality that openconnect simply does for free for us, it is
not worth it, I think.
(cherry picked from commit ea54b7f2c0)
It should eventually move into libnm and ideally the data be obtained from VPN
plugins.
(No functional change, only moving the function).
(cherry picked from commit 6dd1e2673e)
The macro EWOULDBLOCK is another name for EAGAIN; they are always the
same in the GNU C Library.
https://www.gnu.org/savannah-checkouts/gnu/libc/manual/html_node/Error-Codes.html
Otherwise, we would need a workaround for EWOULDBLOCK too, because
libnl maps that to NLE_FAILURE. So we would have to detect EAGAIN
as (nle == -NLE_FAILURE && errno == EWOULDBLOCK).
(cherry picked from commit d2fab2df54)
When the errno was accidentally set to EAGAIN or EWOULDBLOCK,
we would only read one single message and return that there is
nothing to read.
This means, if there were more then one messages ready to read,
we would only read the first one and return to the main-loop
(which then again calls back to platform as more data is ready
to be read).
(cherry picked from commit 10b684b827)
Change the name of the file where to store the results
of the valgrind run.
Previously the file had a prefix "valgrind-", which is inconvinient.
Instead, have the file using the same name as the test executable,
with a ".valgrind-log" suffix.
(cherry picked from commit ce238a7074)
dhclient adds a trailing dot to domain search list entries received
from the server, while the same domains received by other means
(dhcpcd on RA) don't have the final dot. The result is that
resolv.conf can be populated with duplicated entries.
Fix this by stripping the trailing dot when a new search domain is
added to a IP configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758777
(cherry picked from commit 6e990cf97b)
Failed to lookup pppoe_binary, which results in a failed assertion
NetworkManager:ERROR:ppp-manager/nm-ppp-manager.c:949:create_pppd_cmd_line: assertion failed: (pppoe_binary != NULL)
https://bugzilla.gnome.org/show_bug.cgi?id=759001
Fixes: 7955806a02
Unslaving from a bridge causes a wrong RTM_DELLINK event for
the former slave.
# ip link add dummy0 type dummy
# ip link add bridge0 type bridge
# ip link set bridge0 up
# ip link set dummy0 master bridge0
# ip monitor link &
# ip link set dummy0 nomaster
18: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master bridge0 state DOWN group default
link/ether 76:44:5f:b9:38:02 brd ff:ff:ff:ff:ff:ff
18: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether 76:44:5f:b9:38:02
Deleted 18: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether 76:44:5f:b9:38:02
18: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
link/ether 76:44:5f:b9:38:02 brd ff:ff:ff:ff:ff:ff
19: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
19: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
Previously, during do_request_link() we would remember the link that is
about to be requested (delayed_deletion) and delay processing a new
RTM_DELLINK message until the end of do_request_link() -- and possibly
forget about about the deletion, if RTM_DELLINK was followed by a
RTM_NEWLINK.
However, this hack does not catch the case where an external command
unslaves the link.
Instead just accept the wrong event and raise a "removed" signal right
away. This brings the cache in an externally visible, wrong state that
will be fixed by a following "added" signal.
Still do that because working around the kernel bug is complicated. Also,
we already might emit wrong "added" signals for devices that are already
removed. As a consequence, a user should not consider the platform signals
until all events are processed.
Listeners to that signal should accept that added/removed link changes
can be wrong and should preferably handle them idly, when the events
have settled.
It can even be worse, that a RTM_DELLINK is not fixed by a following
RTM_NEWLINK:
...
# ip link set dummy0 nomaster
36: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop master bridge0 state DOWN
link/ether e2:f2:20:98:3a:be brd ff:ff:ff:ff:ff:ff
36: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether e2:f2:20:98:3a:be
Deleted 36: dummy0: <BROADCAST,NOARP> mtu 1500 master bridge0 state DOWN
link/ether e2:f2:20:98:3a:be
37: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
37: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
So, when a slave is deleted, we have to refetch it too.
https://bugzilla.redhat.com/show_bug.cgi?id=1285719
(cherry picked from commit 8a87a91813)
Conflicts:
src/platform/nm-linux-platform.c
src/platform/tests/test-link.c
On some kernels (at least RHEL-7.2) we receive a spurious RTM_NEWLINK
message after the RTM_DELLINK message for deleting a bond master.
On RHEL-7, the following commands give:
# ip link add dummy0 type dummy
# ip link add bond0 type bond
# ip link set bond0 up
# ip link set dummy0 master bond0
# ip monitor link &
# ip link del bond0
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
Deleted 21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
^^^^^^^^^^^^^^^ RTM_NEWLINK after RTM_DELLINK (and there follows no
RTM_DELLINK afterwards)
21: bond0: <BROADCAST,MULTICAST,MASTER> mtu 1500 qdisc noop state DOWN
link/ether da:ee:58:70:6f:e5 brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
20: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noqueue state DOWN
link/ether 1e:a6:6c:81:c1:8d brd ff:ff:ff:ff:ff:ff
Fix that by reverting clear_REFRESH_LINK(). This fix has two downsides:
- on kernels where this hack is not necessary, we unnecessarily refetch
a link
- the platform cache first removes the link, adds it again and removes
it. This is ugly, but should have no real consequences because all
listeners to the platform signals delay processing the signals to an
idle handler.
https://bugzilla.redhat.com/show_bug.cgi?id=1285719
This reverts commit f4f4e1cf09 (on master).
This reverts commit 91c00072f2 (on nm-1-0).
(cherry picked from commit 83240f24ae)
The related bug rh#1285827 in kernel causes a missing IFLA_LINK/parent
attribute when creating a veth pair:
# ip monitor link &
[1] 6745
# ip link add dev vm1 type veth peer name vm2
30: vm2@NONE: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
link/ether be:e3:b7:0e:14:52 brd ff:ff:ff:ff:ff:ff
31: vm1@vm2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN
link/ether da:e6:a6:c5:42:54 brd ff:ff:ff:ff:ff:ff
Add a workaround and test.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1285827
(cherry picked from commit 5650c82a8e)
Conflicts:
src/platform/nm-linux-platform.c
src/platform/tests/test-link.c
Also move the initilization of the instance into the constructed()
method.
NMAgentManager now owns a reference to the DBUS manager and Auth
manager and the dispose() function properly unregisters itself from
both.
(cherry picked from commit 3af40acf31)
