The setting names used when inserting a setting into the hash
table are const since they are derived from GObject internals,
so there's no need to strdup them.
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.
