When the default leasefile location got moved from distro-specific
dhclient locations to a single NM-specific location, that apparently
broke scripts and external tools that depended on the old location,
like dract netbooting.
During a netboot, DHCP is started from the initramfs and gets a
lease, and the leasefile lives in the initramfs. When the real
system is started, and the rootfs switches from the initramfs to
the actual rootfs, something needs to copy the leasefiles over to
where NetworkManager can find them. For dracut at least, various
dracut scripts were doing this, and copying to the old location
in /var/lib/dhclient or /var/lib/dhcp. Which means NM can no
longer find them, and proceeds to acquire a new DHCP lease when
taking over the existing connection, rather than renewing the
existing lease. This can lead to loss of network connectivity
and thus the netboot process fails.
If no leasefile for the connection in the new location exists,
look in the old locations and copy that leasefile over to the new
location.
Simplify code by using property get functions, with most of them
autogenerated based on GObject properties and GValue transforms.
Based on a patch from Jiří Klimeš
GLib-GObject-WARNING **: g_object_get_property: object class `NMSetting8021x' has no property named `pin'
GLib-GObject-WARNING **: g_object_get_property: object class `NMSetting8021x' has no property named `pin-flags'
MM won't always be present, and if it's not, your logs will fill up
with warnings about MM not being able to be launched. And when
running with systemd, you'll get a different class of errors like:
<warn> error poking ModemManager: GDBus.Error:org.freedesktop.systemd1.LoadFailed:
Unit dbus-org.freedesktop.ModemManager1.service failed to load: No such file or
directory. See system logs and 'systemctl status
dbus-org.freedesktop.ModemManager1.service' for details.
and I'm tired of chasing and special-casing all the launch-failed
errors that D-Bus and systemd use.
Plus, we have dynamic log level changing via the D-Bus interface so if
people need to debug this, just chaning the log level will tell you
what's wrong.
The PPP interface may be gone already, especially if the connection
was terminated by the PPP peer. It's pointless to warn in these
cases since getitng the final stats is best-effort anyway.
Because _device_update_description() freed and update *both* the
vendor and product description, if the function was not able to
read one of them the first time, it would throw both away the second
time and try re-read them. That caused code like this:
vendor = nm_device_get_vendor (device);
product = nm_device_get_product (device);
to be left with a freed 'vendor' value if _device_update_description()
could not read the product when first called from nm_device_get_vendor(),
because it would be called a second time from nm_device_get_product()
and free priv->vendor and priv->product and then attempt to re-read them.
Fix this by making the function return only one value so that the
callers can control the liftime of the property they are trying to set.
==29355== Invalid read of size 8
==29355== at 0x38F7289840: __GI_mempcpy (memcpy.S:122)
==29355== by 0x38F7276F21: _IO_file_xsputn@@GLIBC_2.2.5 (fileops.c:1353)
==29355== by 0x38F7247DA6: vfprintf (vfprintf.c:1615)
==29355== by 0x38F7250E28: printf (printf.c:34)
==29355== by 0x41E79F: print_fields (utils.c:351)
==29355== by 0x414CAB: show_device_info (devices.c:636)
==29355== by 0x415CE8: do_devices (devices.c:1094)
==29355== by 0x41D9A9: start (nmcli.c:121)
==29355== by 0x38F6E47A54: g_main_context_dispatch (gmain.c:2715)
==29355== by 0x38F6E47D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==29355== by 0x38F6E48181: g_main_loop_run (gmain.c:3484)
==29355== by 0x40CB89: main (nmcli.c:359)
==29355== Address 0x50a0401 is 1 bytes inside a block of size 18 free'd
==29355== at 0x4A077E6: free (vg_replace_malloc.c:446)
==29355== by 0x38F6E4D79E: g_free (gmem.c:252)
==29355== by 0x4C55F53: _device_update_description (nm-device.c:1417)
==29355== by 0x4C56D26: nm_device_get_product (nm-device.c:1502)
==29355== by 0x414B16: show_device_info (devices.c:620)
==29355== by 0x415CE8: do_devices (devices.c:1094)
==29355== by 0x41D9A9: start (nmcli.c:121)
==29355== by 0x38F6E47A54: g_main_context_dispatch (gmain.c:2715)
==29355== by 0x38F6E47D87: g_main_context_iterate.isra.24 (gmain.c:3290)
==29355== by 0x38F6E48181: g_main_loop_run (gmain.c:3484)
==29355== by 0x40CB89: main (nmcli.c:359)
Not all systems have machine-id in /etc, some still have it in /var/lib/dbus/
especially if they aren't using systemd. Furthermore, if we don't have
any machine-id file (like in the future, if we don't have a messaebus
daemon running) fall back to a random DUID as a last resort.
Like if the dbus daemon restarts; in this case the connection has changed
and the new connection doesn't have the filter installed, and libdbus
aborts when we try to remove a filter that doesn't exist on the connection.
Fix that by re-adding the filter when the connection changes.
Just like we don't fail IPv4 if DHCP fails to get DNS servers,
don't fail IPv6 if we've already got an RA and for some reason
DHCPv6 fails. otherconf/info-only DHCP is not mandatory, and
lack of results thus should not fail the entire IPv6 config,
since DNS servers can also be passed in the RA.
RFC4861:
1-bit "Other configuration" flag. When set, it
indicates that other configuration information is
available via DHCPv6. Examples of such information
are DNS-related information or information on other
servers within the network.
libnm-glib's public headers include headers from libnm-util. While it
does work to just $(pkg-config --cflags --libs libnm-glib), this is
only because libnm-glib has a requires on NetworkManager which happens
to use the same include directory as libnm-util.
The correct dependency chain is thus:
libnm-glib -> libnm-util -> NetworkManager
Signed-off-by: Colin Walters <walters@verbum.org>
Do NMSettingConnection:interface-name matching on the client side as
well, so that, eg, nm-applet does not list connections under the wrong
device.
(Also, move some return-if-fail checks from the subclass method
implementations into the wrapper function.)
https://bugzilla.gnome.org/show_bug.cgi?id=693684
