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.
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
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
0 means "turn off connectivity checking", so we can't use that to
determine whether or not the interval has already been set by
command-line options or not. Instead, store the interval
internally as a signed int and use -1 to mean "not yet set".
Second, validate input values for interval to ensure they can't
be less than 0 or more than G_MAXINT.
STP defaults to yes in NetworkManager (and the initscripts), so a missing
STP value in an ifcfg file means yes/on. Calling svSetValue(STP, NULL)
clears that line from the ifcfg, and thus STP gets interpreted as yes.
Explicitly set stp to "no" so that the value actually gets saved.
==23089== 38,232 (4,248 direct, 33,984 indirect) bytes in 177 blocks are definitely lost in loss record 5,122 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B9068CA1: g_slice_alloc (gslice.c:1003)
==23089== by 0x39B98371B1: g_value_array_new (gvaluearray.c:140)
==23089== by 0x31FB81B67D: valuearray_constructor (dbus-gvalue-utils.c:771)
==23089== by 0x42DD8F: get_property (nm-device.c:4675)
==23089== by 0x39B9819C64: g_object_get_property (gobject.c:1289)
==23089== by 0x31FB80DA49: object_registration_message (dbus-gobject.c:1322)
==23089== by 0x363961DA44: _dbus_object_tree_dispatch_and_unlock (dbus-object-tree.c:858)
==23089== by 0x363960FA82: dbus_connection_dispatch (dbus-connection.c:4685)
==23089== by 0x31FB80AC44: message_queue_dispatch (dbus-gmain.c:90)
==23089== by 0x39B904EC54: g_main_context_dispatch (gmain.c:2539)
'device' is freed by nm_ip6_manager_cancel_addrconf(). Plus if
addrconf fails, the DHCP options should be ignored anyway.
==23089== Thread 1:
==23089== Invalid read of size 4
==23089== at 0x4861E0: finish_addrconf (nm-ip6-manager.c:444)
==23089== by 0x39B904F7EA: g_timeout_dispatch (gmain.c:3882)
==23089== by 0x39B904EC54: g_main_context_dispatch (gmain.c:2539)
==23089== by 0x39B904EF87: g_main_context_iterate.isra.23 (gmain.c:3146)
==23089== by 0x39B904F381: g_main_loop_run (gmain.c:3340)
==23089== by 0x426188: main (main.c:614)
==23089== Address 0xcdb791c is 60 bytes inside a block of size 152 free'd
==23089== at 0x4A07786: free (vg_replace_malloc.c:446)
==23089== by 0x39B905499E: g_free (gmem.c:252)
==23089== by 0x39B90692FE: g_slice_free1 (gslice.c:1111)
==23089== by 0x39B903EC49: g_hash_table_remove_internal (ghash.c:1274)
==23089== by 0x4861DC: finish_addrconf (nm-ip6-manager.c:443)
==23089== by 0x39B904F7EA: g_timeout_dispatch (gmain.c:3882)
==23089== by 0x39B904EC54: g_main_context_dispatch (gmain.c:2539)
==23089== by 0x39B904EF87: g_main_context_iterate.isra.23 (gmain.c:3146)
==23089== by 0x39B904F381: g_main_loop_run (gmain.c:3340)
==23089== by 0x426188: main (main.c:614)
Just code cleanup: This is much less error-prone than manual nesting,
and will mesh very well with future changes to use the libgsystem
cleanup macros.
Accomodate nm-netlink-monitor.c to the change by moving around utility
functions and making them static (removing if not used). Unsubscription
of rtnl groups is not necessary and the whole process will be eventually
moved to nm-platform.
Confusingly, nm-platform-compat's rtnl_link_set_oif adds a new nexthop
with ifindex set, while rtnl_link_set_gateway sets gateway for an
existing nexthop. Keeping the behavior to avoid potential problems.
device_sync_from_netlink() and nm_netlink_request_ip6_info() are now
delayed, so that they are called only once for a series of events. This
makes the IPv6 processing and especially debug messages more sane.
NL_AUTO_PROVIDE is not a valid flag for this call and it's coincidental
with ROUTE_CACHE_CONTENT, which is certainly not what we want.
NETLINK_ROUTE is a netlink family, not an address family. It is
coincidental with AF_UNSPEC which is what we actually want.
Stop logging the whole list of addresses as we already have new and lost
addresses logged. Stop putting 'state' and 'ra_flags' in almost every
message since changes of those are already logged. Log target state
change.
The config file can specify a dhclient script, which gets used instead
of what NM passes on the command-line. Make sure that script gets
ignored in the final dhclient config, because the script NM passes
is the script that needs to be used to pass data back to NM. People
may have old dhclient.conf files lying around that get picked up and
we don't want any script specified there to interfere.
