GitLab

It makes the initializations more explicit.
G_VALUE_INIT is available since glib 2.30, and NM now require glib >= 2.32

--without-valgrind will now work properly.

Use @VALGRIND_RULES@ in Makefile.am for modules that you want to check
for memory leaks.

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)

The initscripts interpreted it this way, so we do too.

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.

Prevents:

NetworkManager[19405]: nm_setting_ip6_config_get_dhcp_hostname: assertion `NM_IS_SETTING_IP6_CONFIG (setting)' failed

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.

DHCP server won't send 'Static Route' option to the client if it is not
explicitly requested.

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>

[keyfile]
unmanaged-devices=interface-name:eth0

So that the description is in the generated documentation and nm-settings(5)
manual page.

This reverts commit 272335a2.

Done by mistake. Sorry.

nm-netlink-monitor is deprecated and the only consumer that still uses
it is nm-ip6-manager, which will start it on its own.

Conflicts:
	src/main.c

It will be activated by the first module that needs it.

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

Virtual devices often don't have stable hardware addresses. So allow
for marking a device unmanaged via its interface name instead.

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

If an NMConnection specifies an interface-name, it is only compatible
with a device with the same iface.

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

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

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

As with the other connection-matching methods, move the loop and the
device-independent bits into NMDevice. By reusing
nm_device_check_connection_compatible(), this means that most device
types now no longer need any type-specific code for this.

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

nm_device_connection_match_config() sounded more generic than it
really was; rename it to nm_device_find_assumable_connection(), which
is what it really does.

There was also a lot of redundancy/cut+paste in the subclass
implementations of connection_match_config(); Improve things by moving
the looping-over-connections code into NMDevice itself, and also doing
the general-device-compatibility and IP-config checking there, leaving
the device subclasses to just verify L2 properties. Which most of them
aren't doing...

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

Since NMDevice has a generic get_hw_address() method now, it can do
nm_device_spec_match_list() itself (for everything except ethernet,
which needs to match against s390 subchannels too).

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

nm_device_connection_match_config() on an ethernet connection could
succeed for a device that was in the connection's
mac-address-blacklist, but then NM would immediately fail to activate
the connection because nm_device_connection_compatible() would check
the blacklist and return FALSE. Fix the former to match the latter.

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

- fix g_set_error()/g_set_error_literal() usage
- make the error messages translatable
- use g_prefix_error() to prepend property name

in hw_take_down()

usb 1-3: USB disconnect, device number 6
modem-manager[547]: <info>  (tty/ttyACM0): released by modem /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3
<info>  (tty/ttyACM0): released by modem /sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3
<info> (ttyACM0): device state change: disconnected -> unmanaged (reason 'removed') [30 10 36]
<info> (ttyACM0): cleaning up...
<info> (ttyACM0): taking down device.
nm_system_iface_set_up: assertion `ifindex > 0' failed