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)
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.
