When connected to a phone via bluetooth and turning bluetooth off on the
computer NetworkManegr crashed due to accessing invalid device.
Reproducer:
- activate bluetooth on a computer and a phone
- pair the devices
- $ nmcli con add type blue con-name phone bt-type panu addr 00:17:EA:84:E7:41
- turn off bluetooth on computer (either with a hardware or software switch)
https://bugzilla.redhat.com/show_bug.cgi?id=1059494
Without this header Buildroot's build complains about unknown
types like GFile etc.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Haller <thaller@redhat.com>
_rebase_relative_time_on_now() is used both by _address_get_lifetime()/nm_platform_ip[46]_address_sync()
and the to_string() functions.
In the latter case, we want to print the original value, without padding. Otherwise in
the addresses are printed in the logs with an additional 5 seconds
padding, which is confusing.
For adding addresses in platform however, we still want to keep the
padding. So pass it on as additional parameter.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Something changed at some point so that NMManager was now recomputing
its state after a connection was activated, but before NMPolicy had
decided whether to give that connection the default route, meaning
NMManager would set the state to CONNECTED_LOCAL rather than
CONNECTED_GLOBAL.
Fix this by watching the active connection :default and :default6
properties too, so we do the right thing regardless of what order the
AC properties change in.
To ensure that NetworkManager does not block needlessly for events
which have no scripts, require scripts that respond to blocking
events to opt into the action.
Since the event loop isn't running on quit, but we want to ensure that
scripts can fully process the DOWN event, block on scripts completing
when disconnecting the VPN when quitting.
This event runs before a connection/device is announced as
"activated" or "connected", to enable scripts to do things
before applications begin using connectivity. For example,
this could be used to manage /etc/resolv.conf outside of
NetworkManager and ensure that resolv.conf had correct
information before DNS is used.
Note that this is different than the Debian or Gentoo "pre-up"
event used in /etc/network/interfaces, as that event runs before
any L2 configuration has started. If we really need an event
like that, we'll add it later as "lower-up".
Thomas pointed out that using the address of the DispatcherInfo
structure as the dispatcher call ID could cause a mis-cancelation
if malloc re-used the same block in the future. While the code
should be correctly clearing call IDs after the callback runs
or is canceled, just use numeric IDs to avoid potential crashses.
On shutdown we can't defer the response to a callback, so we need to
use synchronous D-Bus calls. Second, sometimes we want to block on
the dispatcher response, like for pre-down.
If there are no dispatcher scripts, don't bother dispatching any
events. This saves some time configuring networking if the event
would have no effect anyway.
The NMDevice dispose() function contained some badly-duplicated logic
about when to deactivate a device on its last ref. This logic should
only run when the device is removed by the manager, since the manager
controls the device's life-cycle, and the manager knows best when to
clean up the device. But since it was tied to the device's refcount,
it could have run later than the manager wanted, or not at all.
It gets better. Dispose duplicated logic that was already done in
nm_device_cleanup(), and then *called* nm_device_cleanup() if the
device was still activated and managed. But the manager already
unmanages the device when removing it, which triggers a call to
nm_device_cleanup(), takes the device down, and resets the IPv6
sysctl properties, which dispose() duplicated too. So by the time
dispose() runs, the device should already be unmanaged if the
manager wants to deconfigure it, and most of the dispose() code
should be a no-op.
Clean all that up and remove duplicated functions. Now, the flow
should be like this:
1) manager decides to remove the device and calls remove_device()
2) if the device should be deconfigured, the manager unmanages
the device
3) the NMDevice state change handler tears down the active connection
via nm_device_cleanup() and resets IPv6 sysctl properties
4) when the device's last reference is finally released, only internal
data members are freed in dispose() because the device should
already have been cleaned up by the manager and be unmanaged
5) if the device should be left running because it has an assumable
connection, then the device is not unmanaged, and no cleanup
happens in the state change handler or in dispose()
Ensure autoip4 is cleaned up when disposing, like we clean up DHCP.
Move things that only free stuff to finalize(), and move things that
unref stuff to dispose (eg, the Firewall Manager stuff).
The following procedure leaves an NMActiveConnection around for a deactivated
device, which causes errors in libnm-glib clients when they cannot create the
GObject for the non-existent device of the AC.
1) allow a device which can assume connections to be activated
2) stop NM, which should leave the device's IP configuration up
3) start NM and allow it to assume the device's existing connection
4) remove the device, either by unplugging it or 'rmmod'
The device is removed by nm-manager.c::remove_device(), but the device object
is not moved to UNMANAGED state, leaving the NMActiveConnection completely
unaware the device has gone away.
The nm-manager.c::remove_device() code did not correctly handle moving a
forcibly removed (eg, by unplugging or 'ip link del' or 'rmmod') device to
the UNMANAGED state when the device was active with an assumed connection.
To fix this, make the conditions when the device should be deactivated
on removal much more explicit.
A device should be deactivated on removal if:
1) it is forcibly removed, eg by the kernel network interface being
removed due to 'ip link del' or hotplugging, or internally by NM due
to a parent WWAN interface taking priority over a WWAN ethernet interface
2) if the device cannot assume connections, in which case NetworkManager
must have activated the device and since we cannot assume the connection
on restart, we should deactivate it
3) if the device is not activated, to ensure that its IPv6 parameters
and other things get reset to the pre-NetworkManager values
https://bugzilla.gnome.org/show_bug.cgi?id=729833
dhcp6_cleanup() frees priv->dhcp6_ip6_config so dispose() doesn't need
to do that. Also use g_clear_object() when appropriate.
Lastly, notify that the DHCP4/6 config objects have changed *after*
clearing them, so that the PropertiesChanged signal is emitted with a
blank path to indicate the object is gone. Previously the PC signal
would have been emitted with the valid path of the DHCP4/6 config object,
but the object would already be dead.
For any function in nm-device.h which is not used outside of
nm-device.c, remove the public prototypes. Functions that
are actually used get moved above their caller, and functions
that have no callers are removed.
Move the GObject-related stuff to the bottom of the file and get
rid of no-longer-necessary forward prototypes since the stuff that
required those prototypes is now below the implementation.
Future patches will allow blocking dispatcher calls, which we
don't want to happen when deactivating a VPN connection during
normal operation. So move code that stops VPN connections outside
of the VPNService object's dispose() function and require the object
that owns the VPNService (the VPNManager) to stop connections at the
right times.
When quitting, blocking calls are acceptable (because NetworkManager's
D-Bus interface is no longer useful, plus we can't easily schedule
callbacks because no mainloop is running), so it's ok to stop
connections from NMVPNManager:dispose.
D-Bus already watches the life-cycle, and we'll get a NameOwnerChanged
signal when the VPN service daemon quit. So the GLib child watch is
just duplicated code that we don't need. Remove it.
Since NM_VPN_CONNECTION_STATE_* are linear in number and defined API,
we can't add a DEACTIVATING state in the right place. So create a
NMVPNConnection internal VPN state and convert that to the old
NM_VPN_CONNECTION_STATE_* numbers at exit points from the object.
(This will also allow us to get rid of priv->secrets_req in the future
and fold that into the VPN states)
Instead of telling a VPN service to quit, leave that up to the service
itself. Services based on libnm-glib-vpn already have a quit timeout
of 20 seconds. We also eventually want to D-Bus activate the VPN
services, and at that point we won't have a PID we can send signals
to.
