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
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.
==7347== 1,201 bytes in 1 blocks are definitely lost in loss record 5,016 of 5,107
==7347== at 0x4A06B0F: calloc (vg_replace_malloc.c:593)
==7347== by 0x39B90548E6: g_malloc0 (gmem.c:189)
==7347== by 0x39B9026F8D: g_base64_decode (gbase64.c:407)
==7347== by 0x4C51CA1: parse_old_openssl_key_file (crypto.c:227)
==7347== by 0x4C51EC3: crypto_decrypt_private_key_data (crypto.c:497)
==7347== by 0x4C529BE: crypto_verify_private_key_data (crypto.c:706)
==7347== by 0x4C52B7B: crypto_verify_private_key (crypto.c:735)
==7347== by 0x4C5CCC5: nm_setting_802_1x_set_private_key (nm-setting-8021x.c:1633)
==7347== by 0xC8F64D4: eap_tls_reader (reader.c:2270)
==7347== by 0xC8F4886: fill_8021x (reader.c:2704)
==7347== by 0xC8F8311: wireless_connection_from_ifcfg (reader.c:2825)
==7347== by 0xC8FAFD2: connection_from_file (reader.c:4303)
==23089== 342 bytes in 38 blocks are definitely lost in loss record 4,870 of 5,123
==23089== at 0x4A0881C: malloc (vg_replace_malloc.c:270)
==23089== by 0x39B905488E: g_malloc (gmem.c:159)
==23089== by 0x39B906A4BB: g_strdup (gstrfuncs.c:356)
==23089== by 0x31FC02DA90: set_property (nm-setting-pppoe.c:220)
==23089== by 0x39B9819972: g_object_set_property (gobject.c:1352)
==23089== by 0x31FC01A9A7: nm_setting_enumerate_values (nm-setting.c:589)
==23089== by 0x31FC01AA81: nm_setting_duplicate (nm-setting.c:264)
==23089== by 0x31FC01633B: duplicate_cb (nm-connection.c:1182)
==23089== by 0x39B903F8DF: g_hash_table_foreach (ghash.c:1524)
==23089== by 0x31FC01756C: nm_connection_duplicate (nm-connection.c:1203)
==23089== by 0x4A7BE3: get_settings_auth_cb (nm-settings-connection.c:1062)
==23089== by 0x4A5624: auth_start (nm-settings-connection.c:1008)
'str' was not freed anywhere.
==23089== 2,072 (24 direct, 2,048 indirect) bytes in 1 blocks are definitely lost in loss record 5,063 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 0x39B906C7FA: g_string_sized_new (gstring.c:121)
==23089== by 0x39B906CE75: g_string_new_len (gstring.c:186)
==23089== by 0x31FC0149CE: parse_old_openssl_key_file (crypto.c:150)
==23089== by 0x31FC014E33: crypto_decrypt_private_key_data (crypto.c:494)
==23089== by 0x31FC01592E: crypto_verify_private_key_data (crypto.c:703)
==23089== by 0x31FC015AEB: crypto_verify_private_key (crypto.c:732)
==23089== by 0x31FC0200E5: nm_setting_802_1x_set_private_key (nm-setting-8021x.c:1640)
==23089== by 0xC694304: eap_tls_reader (reader.c:2280)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
If the certificate's format was valid, but we're asked to refer to it by
paths instead of using the raw data, 'data' would be leaked.
==23089== 8,232 (40 direct, 8,192 indirect) bytes in 1 blocks are definitely lost in loss record 5,109 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 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01ED26: nm_setting_802_1x_set_client_cert (nm-setting-8021x.c:819)
==23089== by 0xC6944A4: eap_tls_reader (reader.c:2316)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089==
==23089== 8,352 (160 direct, 8,192 indirect) bytes in 4 blocks are definitely lost in loss record 5,110 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 0x39B9024539: g_array_sized_new (garray.c:195)
==23089== by 0x31FC0146EA: file_to_g_byte_array (crypto.c:319)
==23089== by 0x31FC01543B: crypto_load_and_verify_certificate (crypto.c:606)
==23089== by 0x31FC01E5E6: nm_setting_802_1x_set_ca_cert (nm-setting-8021x.c:538)
==23089== by 0xC694DD8: eap_peap_reader (reader.c:2358)
==23089== by 0xC692756: fill_8021x (reader.c:2714)
==23089== by 0xC696151: wireless_connection_from_ifcfg (reader.c:2832)
==23089== by 0xC698E3A: connection_from_file (reader.c:4316)
==23089== by 0xC69135C: nm_ifcfg_connection_new (nm-ifcfg-connection.c:119)
==23089== 7,293 (1,248 direct, 6,045 indirect) bytes in 39 blocks are definitely lost in loss record 5,100 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 0x39B9024E90: g_ptr_array_sized_new (garray.c:884)
==23089== by 0x31FB81B3FC: ptrarray_copy (dbus-gvalue-utils.c:1047)
==23089== by 0x31FB81845C: proxy_value_copy (dbus-gtype-specialized.c:446)
==23089== by 0x39B980F51E: g_boxed_copy (gboxed.c:359)
==23089== by 0x31FC03134C: set_property (nm-setting-wired.c:619)
==23089== by 0x39B9819972: g_object_set_property (gobject.c:1352)
==23089== by 0x31FC01A9A7: nm_setting_enumerate_values (nm-setting.c:589)
==23089== by 0x31FC01AA81: nm_setting_duplicate (nm-setting.c:264)
==23089== by 0x31FC01633B: duplicate_cb (nm-connection.c:1182)
==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)
