GitLab

Signed-off-by: Thomas Haller <thaller@redhat.com>

One of the connetions may not have a MAC address, so don't expect one.

Causes the following failure:

   $ /bin/nmcli connection add type ethernet con-name connie ifname '*'

   (process:13883): GLib-CRITICAL **: g_strchug: assertion `string != NULL' failed
   (process:13883): GLib-CRITICAL **: g_strchomp: assertion `string != NULL' failed
   Error: invalid connection type; '' not among [generic, ...].

Regression introduced by commit bfb1200b.
Signed-off-by: Thomas Haller <thaller@redhat.com>

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.

https://bugzilla.gnome.org/show_bug.cgi?id=387832
https://bugzilla.redhat.com/show_bug.cgi?id=1048345
https://bugzilla.redhat.com/show_bug.cgi?id=982734

Since NM now handles long-running dispatcher scripts better, allow them
to run for really long times.

glib doesn't like it, plus we don't use the error anyway, so just
return the constant error string.

Attach a request ID to every request, and print that out in the debug
messages so you can see which results match up with which dispatcher
requests.

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.

Like VPN connections, block on dispatcher scripts when quitting.  Since
the event loop is no longer running we can't schedule callbacks.

https://bugzilla.gnome.org/show_bug.cgi?id=387832

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.

https://bugzilla.gnome.org/show_bug.cgi?id=387832

Oddly, this increases the compiled+stripped size of the object file
by 24 bytes (8296 -> 8320), but I think it produces more readable code.

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()

dispose() and nm_device_cleanup() both do common tasks; consolidate
these common tasks in one place and call when appropriate.

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.

Nothing used its return value or passed FALSE.

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.

Saves some code and a memory allocation.

Group most of the simple getters together near the top, and remove
getters that have no callers (mtu, firmware-version).

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.