Currently the three parameters for the connectivity check (uri, interval, response)
don't get reset. Soon they might be modified at any time when reloading the
configuration.
When calling the asynchronous HTTP connectivity check, we want to
preserve the original parameters so that the result callback still can
access them later. Pass the uri and response parameter on as
ConCheckCbData.
In case of error, ibft prints an error message to stderr
with two trailing newlines. This causes multiple lines
in our logfile. Replace newlines in the error message
by whitespaces.
The manager wrote the user state to the state file in /var with
the key "WiMAXEnabled", but it was read from the state file as
"WimaxEnabled". Clearly that's not going to work.
Before, the Wi-Fi plugin was always build. Users who didn't want
to use it would simply drop "libnm-device-plugin-wifi.so".
Add a compile time option to disable needlessly building the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=743388
Note also the comment "Just make sure we don't expect specific data being
in the connection till then (especially in validate_activation_request())."
in impl_manager_add_and_activate_connection().
Creating a connection caused a failed assertion:
#0 0x00007ff8da3aa4e9 in g_logv (log_domain=0x7ff8ddf41036 "NetworkManager", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffff5a0a090) at gmessages.c:989
#1 0x00007ff8da3aa63f in g_log (log_domain=<optimized out>, log_level=<optimized out>, format=<optimized out>) at gmessages.c:1025
#2 0x00007ff8dde8c47a in nm_utils_get_ip_config_method (connection=0x7ff8def21d20, ip_setting_type=140706868598912) at NetworkManagerUtils.c:1252
#3 0x00007ff8dde7d654 in validate_activation_request (self=0x7ff8def62150, context=0x7ff8deff5a00, connection=0x7ff8def21d20, device_path=0x7ff8def3f770 "/org/freedesktop/NetworkManager/Devices/2", out_device=0x7ffff5a0a370,
out_vpn=0x7ffff5a0a36c, error=0x7ffff5a0a378) at nm-manager.c:3061
#4 0x00007ff8dde7b7a2 in impl_manager_add_and_activate_connection (self=0x7ff8def62150, settings=0x7ff8def95460, device_path=0x7ff8def3f770 "/org/freedesktop/NetworkManager/Devices/2",
specific_object_path=0x7ff8deeeced0 "/org/freedesktop/NetworkManager/AccessPoint/227", context=0x7ff8deff5a00) at nm-manager.c:3386
#5 0x00007ff8dde6bd9c in dbus_glib_marshal_nm_manager_VOID__BOXED_BOXED_BOXED_POINTER (closure=0x7ffff5a0a5f0, return_value=0x0, n_param_values=5, param_values=0x7ff8defb9d30, invocation_hint=0x0,
marshal_data=0x7ff8dde7b660 <impl_manager_add_and_activate_connection>) at ./nm-manager-glue.h:189
#6 0x00007ff8dc506885 in invoke_object_method (message=0x7ff8def99a00, connection=0x7ff8deeec940, method=0x7ff8de1a6878 <dbus_glib_nm_manager_methods+72>, object_info=0x7ff8de1a2e70 <dbus_glib_nm_manager_object_info>,
object=0x7ff8def62150) at dbus-gobject.c:1899
#7 object_registration_message (connection=0x7ff8deeec940, message=message@entry=0x7ff8def99a00, user_data=user_data@entry=0x7ff8def16da0) at dbus-gobject.c:2161
#8 0x00007ff8dc2cef86 in _dbus_object_tree_dispatch_and_unlock (tree=0x7ff8deeec5e0, message=message@entry=0x7ff8def99a00, found_object=found_object@entry=0x7ffff5a0a814) at dbus-object-tree.c:862
#9 0x00007ff8dc2c10d9 in dbus_connection_dispatch (connection=connection@entry=0x7ff8deeec940) at dbus-connection.c:4699
#10 0x00007ff8dc503d65 in message_queue_dispatch (source=source@entry=0x7ff8deeee720, callback=<optimized out>, user_data=<optimized out>) at dbus-gmain.c:90
#11 0x00007ff8da3a32a6 in g_main_dispatch (context=0x7ff8deebd320) at gmain.c:3066
#12 g_main_context_dispatch (context=context@entry=0x7ff8deebd320) at gmain.c:3642
#13 0x00007ff8da3a3628 in g_main_context_iterate (context=0x7ff8deebd320, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3713
#14 0x00007ff8da3a3a3a in g_main_loop_run (loop=0x7ff8deebd3e0) at gmain.c:3907
#15 0x00007ff8dddc0979 in main (argc=1, argv=0x7ffff5a0afd8) at main.c:442
Fixes: 477033b9ef
valgrind complains (rightly):
==7702== 15 bytes in 2 blocks are definitely lost in loss record 411 of 6,278
==7702== at 0x4A0645D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7702== by 0x8151E6E: g_malloc (gmem.c:104)
==7702== by 0x816972E: g_strdup (gstrfuncs.c:364)
==7702== by 0x1D6671: nm_properties_changed_signal_add_property (nm-properties-changed-signal.c:235)
==7702== by 0x1AF2D5: nm_dbus_manager_register_exported_type (nm-dbus-manager.c:867)
==7702== by 0x7EE0D3D: g_type_class_ref (gtype.c:2220)
==7702== by 0x7EC9A78: g_object_new_valist (gobject.c:1928)
==7702== by 0x7EC9C10: g_object_new (gobject.c:1559)
==7702== by 0x14A5FC: new_link (nm-device-bridge.c:482)
==7702== by 0x1CF8FD: platform_link_cb (nm-manager.c:2154)
==7702== by 0x988FD8B: ffi_call_unix64 (unix64.S:76)
==7702== by 0x988F6BB: ffi_call (ffi64.c:522)
nm_device_disambiguate_names() will disambiguate them by their
hardware address. This is not very helpful, so detect this case and
use the Bluetooth device name instead.
This function is used by System Settings when showing the list of
network devices.
https://bugzilla.gnome.org/show_bug.cgi?id=740553
(Port of a libnm-gtk patch written by Ryan Lortie.)
During queued_ip_config_change(), we eventually call update_ip_config()
and ip4_config_merge_and_apply(). These functions read the IP configuration
from platform and setup the private ip4_config instance.
Trigger this initialization after constructing the device to setup
the IP configuration.
Before, for unmanaged devices we would not call ip4_config_merge_and_apply()
until the first platform change event.
Note that in the worst case we do some unnecessary work due to this,
because queued_ip_config_change() must already be robust to be called
at any time.
Since 0c136c1e2, we also track the default route for devices
without active-connection (unmanaged). They must not be returned
as best_config() or as best_device(), because the caller don't
expect unmanaged devices here.
This also gets closer to the original behavior of get_best_device()
before merging default-route-manager in d4417e3460
where we also would ignore devices depending on the state.
This fixes an assertion when having an interface unmanaged
and activating it externally:
#0 0x00007ffff6806187 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x00007ffff6807dea in __GI_abort () at abort.c:89
#2 0x00007ffff6c0aec5 in g_assertion_message (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", message=message@entry=0x8c9cb0 "assertion failed: (req)") at gtestutils.c:2356
#3 0x00007ffff6c0af5a in g_assertion_message_expr (domain=domain@entry=0x5332d5 "NetworkManager", file=file@entry=0x539460 "nm-default-route-manager.c", line=line@entry=1056, func=func@entry=0x539920 <__FUNCTION__.28934> "_ipx_get_best_config", expr=expr@entry=0x53132f "req") at gtestutils.c:2371
#4 0x000000000049a196 in _ipx_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=0x0, out_vpn=0x7fffffffd318, vtable=0x7a0a00 <vtable_ip4>, vtable=0x7a0a00 <vtable_ip4>) at nm-default-route-manager.c:1056
#5 0x000000000049a3f6 in nm_default_route_manager_ip4_get_best_config (self=<optimized out>, ignore_never_default=ignore_never_default@entry=1, out_ip_iface=out_ip_iface@entry=0x7fffffffd310, out_ac=out_ac@entry=0x0, out_device=out_device@entry=0x0, out_vpn=out_vpn@entry=0x7fffffffd318) at nm-default-route-manager.c:1079
#6 0x00000000004b7518 in update_ip4_dns (self=0x7ecac0 [NMPolicy], out_vpn=0x7fffffffd318, out_device=0x0, out_ac=0x0, out_ip_iface=0x7fffffffd310, ignore_never_default=1) at nm-policy.c:390
#7 0x00000000004b7518 in update_ip4_dns (dns_mgr=0x8623a0 [NMDnsManager], policy=0x7ecac0 [NMPolicy]) at nm-policy.c:406
#8 0x00000000004b99d5 in device_ip4_config_changed (device=0x8844b0 [NMDeviceEthernet], new_config=0x908aa0 [NMIP4Config], old_config=0x908aa0 [NMIP4Config], user_data=0x7ecac0) at nm-policy.c:1260
#9 0x000000368f405d60 in ffi_call_unix64 () at /lib64/libffi.so.6
#10 0x000000368f4057d1 in ffi_call () at /lib64/libffi.so.6
#11 0x00007ffff6ee5b8c in g_cclosure_marshal_generic_va (closure=0x886a40, return_value=0x0, instance=0x8844b0, args_list=<optimized out>, marshal_data=0x0, n_params=2, param_types=0x87d3a0) at gclosure.c:1541
#12 0x00007ffff6ee5144 in _g_closure_invoke_va (closure=closure@entry=0x886a40, return_value=return_value@entry=0x0, instance=instance@entry=0x8844b0, args=args@entry=0x7fffffffd810, n_params=<optimized out>, param_types=0x87d3a0) at gclosure.c:831
#13 0x00007ffff6eff900 in g_signal_emit_valist (instance=0x8844b0, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffd810) at gsignal.c:3201
#14 0x00007ffff6f0014f in g_signal_emit (instance=instance@entry=0x8844b0, signal_id=<optimized out>, detail=detail@entry=0) at gsignal.c:3348
#15 0x000000000044a1f4 in nm_device_set_ip4_config (self=self@entry=0x8844b0 [NMDeviceEthernet], new_config=new_config@entry=0x9089a0 [NMIP4Config], default_route_metric=default_route_metric@entry=100, commit=commit@entry=0, reason=reason@entry=0x0) at devices/nm-device.c:5866
#16 0x000000000044a5af in ip4_config_merge_and_apply (self=self@entry=0x8844b0 [NMDeviceEthernet], config=config@entry=0x0, commit=commit@entry=0, out_reason=out_reason@entry=0x0) at devices/nm-device.c:3037
#17 0x000000000044b4fd in update_ip_config (self=self@entry=0x8844b0 [NMDeviceEthernet], initial=initial@entry=0) at devices/nm-device.c:6617
#18 0x000000000044bc39 in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6688
#19 0x00007ffff6be4e1b in g_main_context_dispatch (context=0x7ba3a0) at gmain.c:3122
#20 0x00007ffff6be4e1b in g_main_context_dispatch (context=context@entry=0x7ba3a0) at gmain.c:3737
#21 0x00007ffff6be51b0 in g_main_context_iterate (context=0x7ba3a0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3808
#22 0x00007ffff6be54d2 in g_main_loop_run (loop=0x7ba460) at gmain.c:4002
#23 0x000000000043291d in main (argc=1, argv=0x7fffffffdef8) at main.c:442
Fixes: da708059da
Enum types larger then the native 'int' type are undefined behavior
according to C standard. Assert that our compiler does the right thing.
the expression that defines the value of an enumeration constant shall
be an integer constant expression that has a value representable as an
int
We trigger a new solicitation upon seeing the new token. Kernel triggers one
too, but that one is of no use to us, since the advertisement might arrive sooner
than we learn about the token change.
