Now we use init_link to print the rtnllink object, so be more
resilient to incompletly initilized objects and just set the
fields to NULL.
This fixes the (non harmful) warning:
<debug> [1397563880.690580] [platform/nm-linux-platform.c:1950] link_change_flags(): link: change 3: flags set 'up' (1)
init_link: assertion 'rtnl_link_get_name (rtnllink)' failed
file platform/nm-linux-platform.c: line 1021 (to_string_link): should not be reached
<error> [1397563880.690632] [platform/nm-linux-platform.c:1836] link_change(): Netlink error changing link (invalid link 0x7f88b5cf93c0): Unspecific failure
Signed-off-by: Thomas Haller <thaller@redhat.com>
We have to check the previous base device state in process_secondaries() when
making a state change. The device might got disconnected in the meantime and
thus the transition from DISCONNECTED to ACTIVATED or FAILED would have been
incorrect.
Logs showing the problem:
NetworkManager[2655]: <info> (eth0): disconnecting for new activation request.
NetworkManager[2655]: <info> (eth0): device state change: secondaries -> deactivating (reason 'none') [90 110 0]
NetworkManager[2655]: <info> (eth0): device state change: deactivating -> disconnected (reason 'none') [110 30 0]
NetworkManager[2655]: <info> (eth0): deactivating device (reason 'none') [0]
NetworkManager[2655]: <info> (eth0): canceled DHCP transaction, DHCP client pid 11409
NetworkManager[2655]: <info> NetworkManager state is now DISCONNECTED
NetworkManager[2655]: (devices/nm-device.c:6591):nm_device_state_changed: runtime check failed: (priv->in_state_changed == FALSE)
NetworkManager[2655]: <info> (eth0): device state change: disconnected -> failed (reason 'secondary-connection-failed') [30 120 54]
NetworkManager[2655]: <warn> Activation (eth0) failed for connection '<unknown>'
NetworkManager[2655]: <warn> (eth0): add_pending_action (4): 'queued state change to disconnected' already added
NetworkManager[2655]: file devices/nm-device.c: line 7682 (nm_device_add_pending_action): should not be reached
NetworkManager[2655]: <info> Activation (eth0) starting connection 'ethernet-12'
NetworkManager[2655]: <info> Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled...
NetworkManager[2655]: <info> (eth0): device state change: failed -> disconnected (reason 'none') [120 30 0]
NetworkManager[2655]: <info> (eth0): deactivating device (reason 'none') [0]
NetworkManager[2655]: <warn> (eth0): remove_pending_action (2): 'queued state change to disconnected' never added
NetworkManager[2655]: file devices/nm-device.c: line 7733 (nm_device_remove_pending_action): should not be reached
NetworkManager[2655]: <info> VPN service 'openvpn' disappeared
https://bugzilla.redhat.com/show_bug.cgi?id=1055099https://bugzilla.redhat.com/show_bug.cgi?id=1055101
The kernel PPPoE code disconnects when it receives a PADT frame, but
doesn't notify userland about it. So if the server sends a PPPoE PADT
without having sent the standard PPP LCP Termination request first,
then pppd (and thus NetworkManager) will not know that the connection
has been disconnected.
This should eventually be fixed in the kernel, but for now, work
around this by using the userland pppoe client rather than the kernel
code.
These settings are mostly unused. Do not pass them when starting the client,
instead only pass the argument that is actually used (dhcp_client_id).
This simplifies the code later, when we delay starting of DHCP6 clients --
because there is no need to clone the setting.
Signed-off-by: Thomas Haller <thaller@redhat.com>
At a later point, we will have to make a copy of @dhcp_anycast_addr to start
the client asynchronously. Although the length of the guint8 array *should*
always be 6 byte (being a MAC address), it's nicer to just pass on the
GByteArray instance instead, which knows how many byte are actually
set.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Clients such as gnome-control-center or nm-applet show
at some places only one (IPv6) address. They most likely
just pick the first address from the list of addresses,
so we should order them.
Sorting has the advantage to make the order deterministic --
contrary to before where the order depended on run time conditions.
Note, that it might be desirable to show the address that the kernel
will use as source address for new connections. However, this depends
on routing and cannot be easily determined in general. Still, the
ordering tries to account for this and sorts the addresses accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=726525
Signed-off-by: Thomas Haller <thaller@redhat.com>
This is intended to contain utility functions for tests. It will
be header only (containing inline functions).
Signed-off-by: Thomas Haller <thaller@redhat.com>
We can only allow possible match if all the differences are exceptions.
Before, we accepted the connection if an exception was found, but it is wrong
because there may be another difference (that is fatal).
When assuming the connections on restart we want to prefer more-recently-used
connections. That's why we have to sort connections according to timestamps in
descending order. That means connections used more recently (higher timestamp)
go before connections with lower timestamp.
https://bugzilla.redhat.com/show_bug.cgi?id=1067712
Asserting against "/.." is wrong, because one could rename a link to
"..em1", which is a valid ifname but would crash NetworkManager.
Signed-off-by: Thomas Haller <thaller@redhat.com>
No need to allocate a dynamic buffer in most of the cases.
And extended test cases to test with/without white space
and leading zeros.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Instead of waiting until the device is disposed and dbus-glib does
it for us, remove them when the Manager is done with them. If
something (like pending D-Bus calls) holds a reference to the device
when the Manager removes it, the device would previously still
service method calls until all references are released. When
the device is removed, it's dead, and it shouldn't be exported
anymore.
Rebasing the shvar changes to master added some new instances of
svNewFile() and svWriteFile() (in the aliases code) that needed to be
updated for the API changes.
shvar.c was assuming it could do a single read() to read in the ifcfg
file, without taking partial reads or EINTR into account. Fix that.
Also, it was keeping the raw contents of the ifcfg file in the
shvarFile even though it never looked at it after svOpenFile().
(Presumably lineList originally consisted of pointers into arena, but
that had to be changed to support readwrite.) Fix that.
It would simplify things further to use g_file_get_contents() and
g_file_set_contents(), but the current code is perhaps more resilient
to symlink attacks because it keeps the fd open?
activate_data_free() deletes the data from priv->pending_activation_checks,
thus iterating over the list with g_slist_free_full() causes a double
free or invalid memory access.
This bug does not hit easily, because the policy only get's disposed
when NM shuts down and then there are likely no pending activations
queued.
Fixes regression introduced by commit 4f0c70e945.
Signed-off-by: Thomas Haller <thaller@redhat.com>
