Backport to 1.0.6 the following symbols:
- nm_utils_wifi_2ghz_freqs;
- nm_utils_wifi_5ghz_freqs;
Backported by commit 77bf69c3dc6ef6c17741cdf0f81af911378596e0
- fixes value for 'freq_list' wpa_supplicant option
- allows locking to a channel within a band
- adds utility functions for getting Wi-Fi frequencies
https://bugzilla.gnome.org/show_bug.cgi?id=627571
It can happen on a regular basis when many events get raised.
It is probalby not avoidable and most likely not an issue, so
downgrade the warning to info level.
VPN plugins are usually split into different packages. It might
be that the plugin file is simply not installed. We want the caller
to be able to recognize that conditation to fail gracefully.
Thus return a certain error code.
The logging macros _LOGD(), etc. are specific to each
file as they format the message according to their context.
Still, they were cumbersome to define and their implementation
was repeated over and over (slightly different at times).
Move the declaration of these macros to "nm-logging.h".
The source file now only needs to define _NMLOG(), and either
_NMLOG_ENABLED() or _NMLOG_DOMAIN.
This reduces code duplication and encourages a common implementation
and usage of these macros.
Don't clear NMDevice @master in nm_device_cleanup() if the device link
is still enslaved because this causes an inconsistent state in which
the slave in included in the @slaves field of master device but
@master of slave device is NULL.
In such state, if the master link gets deleted, NM receives a change
event for each slave and a deletion event for the master; the change
events should also remove slaves from @slaves of master device, but
since their @master field is NULL the removal can't be performed.
Later, when the master deletion event is received, @slaves is not empty
in dispose() of NMDevice and the following assertion is triggered:
dispose: runtime check failed: (priv->slaves == NULL)
https://bugzilla.redhat.com/show_bug.cgi?id=1243371
The first argument for dispatcher actions is the interface name, except
for the "hostname" action, where no interface is available.
For "hostname" actions continue to pass "none", as there is no interface
available. But for device actions, it may happen that the interface name
is missing too. In this case, don't pass "none" but instead an empty
name.
Program received signal SIGSEGV, Segmentation fault.
g_type_check_instance_cast (type_instance=type_instance@entry=0x89f180, iface_type=9004512) at gtype.c:4060
4060 node = lookup_type_node_I (type_instance->g_class->g_type);
(gdb) bt
#0 0x00007ffff4b44e80 in g_type_check_instance_cast (type_instance=type_instance@entry=0x89f180, iface_type=9004512) at gtype.c:4060
#1 0x000000000056a460 in connection_visibility_changed (connection=0x89f680 [NMKeyfileConnection], pspec=<optimized out>, user_data=0x89f180) at settings/nm-settings.c:870
#5 0x00007ffff4b3b54f in <emit signal notify:visible on instance 0x89f680 [NMKeyfileConnection]> (instance=instance@entry=0x89f680, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3393
#2 0x00007ffff4b200b5 in g_closure_invoke (closure=0x9131a0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7fffffffd540, invocation_hint=invocation_hint@entry=0x7fffffffd4c0) at gclosure.c:801
#3 0x00007ffff4b32499 in signal_emit_unlocked_R (node=node@entry=0x8696b0, detail=detail@entry=641, instance=instance@entry=0x89f680, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7fffffffd540) at gsignal.c:3581
#4 0x00007ffff4b3b1a0 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7fffffffd710) at gsignal.c:3337
#6 0x00007ffff4b24665 in g_object_dispatch_properties_changed (object=0x89f680 [NMKeyfileConnection], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1056
#7 0x00007ffff4b26d11 in g_object_notify (pspec=0x8ce660 [GParamBoolean], object=0x89f680 [NMKeyfileConnection]) at gobject.c:1149
#8 0x00007ffff4b26d11 in g_object_notify (object=0x89f680 [NMKeyfileConnection], property_name=property_name@entry=0x5d2eb9 "visible") at gobject.c:1197
#9 0x0000000000497f85 in set_visible (self=self@entry=0x89f680 [NMKeyfileConnection], new_visible=new_visible@entry=0) at settings/nm-settings-connection.c:296
#10 0x0000000000498165 in dispose (object=0x89f680 [NMKeyfileConnection]) at settings/nm-settings-connection.c:2390
#11 0x00007ffff4b24fec in g_object_unref (_object=0x89f680) at gobject.c:3137
#12 0x00000000004a4a4f in dispose (object=0xa24260 [NMVpnConnection]) at nm-active-connection.c:904
#13 0x00007ffff4b24fec in g_object_unref (_object=0xa24260) at gobject.c:3137
#14 0x0000000000577636 in nm_vpn_service_stop_connections (service=0x8ff610 [NMVpnService], quitting=1, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED) at vpn-manager/nm-vpn-service.c:150
#15 0x0000000000576ea2 in dispose (object=0x921060 [NMVpnManager]) at vpn-manager/nm-vpn-manager.c:284
#16 0x00007ffff4b24fec in g_object_unref (_object=0x921060) at gobject.c:3137
#17 0x00000000004d0f05 in dispose (object=0x88a2b0 [NMManager]) at nm-manager.c:5061
#18 0x00007ffff4b24fec in g_object_unref (_object=0x88a2b0) at gobject.c:3137
#19 0x0000000000444e08 in _nm_singleton_instance_destroy () at NetworkManagerUtils.c:138
#20 0x00007ffff7de97b7 in _dl_fini () at dl-fini.c:252
#21 0x00007ffff4444778 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff47d0618 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#22 0x00007ffff44447c5 in __GI_exit (status=status@entry=0) at exit.c:104
#23 0x0000000000445b80 in main (argc=1, argv=0x7fffffffdf08) at main.c:458
(gdb)
They may be unexported upon shutdown.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffff48271db in _g_log_abort (breakpoint=1) at gmessages.c:316
316 G_BREAKPOINT ();
(gdb) bt
#0 0x00007ffff48271db in g_logv (breakpoint=1) at gmessages.c:316
#1 0x00007ffff48271db in g_logv (log_domain=0x7ffff488d8ce "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7fffffffd4d0) at gmessages.c:1073
#2 0x00007ffff482734f in g_log (log_domain=log_domain@entry=0x7ffff488d8ce "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7ffff48971dd "%s: assertion '%s' failed") at gmessages.c:1111
#3 0x00007ffff4827389 in g_return_if_fail_warning (log_domain=log_domain@entry=0x7ffff488d8ce "GLib", pretty_function=pretty_function@entry=0x7ffff48e7d00 <__func__.5406> "g_variant_is_object_path", expression=expression@entry=0x7ffff48e9af2 "string != NULL") at gmessages.c:1120
#4 0x00007ffff485511a in g_variant_is_object_path (string=<optimized out>) at gvariant.c:1351
#5 0x00007ffff4855129 in g_variant_new_object_path (object_path=0x0) at gvariant.c:1325
#6 0x00000000004b9567 in _dispatcher_call (dhcp6_props=<synthetic pointer>, dhcp4_props=<synthetic pointer>, ip6_builder=0x7fffffffd7b0, ip4_builder=0x7fffffffd730, dev_builder=0x7fffffffd6b0, device=0x9621f0 [NMDeviceEthernet]) at nm-dispatcher.c:242
#7 0x00000000004b9567 in _dispatcher_call (action=action@entry=DISPATCHER_ACTION_VPN_DOWN, blocking=blocking@entry=1, connection=<optimized out>, device=device@entry=0x9621f0 [NMDeviceEthernet], vpn_iface=0x9e2650 "tun1", vpn_ip4_config=vpn_ip4_config@entry=0x0, vpn_ip6_config=0x0, callback=0x0, user_data=0x0, out_call_id=0x0) at nm-dispatcher.c:545
#8 0x00000000004b98c2 in nm_dispatcher_call_vpn_sync (action=action@entry=DISPATCHER_ACTION_VPN_DOWN, connection=<optimized out>, parent_device=parent_device@entry=0x9621f0 [NMDeviceEthernet], vpn_iface=<optimized out>, vpn_ip4_config=vpn_ip4_config@entry=0x0, vpn_ip6_config=vpn_ip6_config@entry=0x0) at nm-dispatcher.c:740
#9 0x0000000000571986 in _set_vpn_state (connection=0xa08270 [NMVpnConnection], vpn_state=<optimized out>, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED, quitting=1) at vpn-manager/nm-vpn-connection.c:427
#10 0x00000000005764b6 in nm_vpn_connection_disconnect (connection=<optimized out>, reason=<optimized out>, quitting=<optimized out>) at vpn-manager/nm-vpn-connection.c:1909
#11 0x000000000057759e in nm_vpn_service_stop_connections (service=0x9aa1c0 [NMVpnService], quitting=1, reason=NM_VPN_CONNECTION_STATE_REASON_SERVICE_STOPPED) at vpn-manager/nm-vpn-service.c:149
#12 0x0000000000576e12 in dispose (object=0x9175a0 [NMVpnManager]) at vpn-manager/nm-vpn-manager.c:284
#13 0x00007ffff4b24fec in g_object_unref (_object=0x9175a0) at gobject.c:3137
#14 0x00000000004d0e75 in dispose (object=0x88a2c0 [NMManager]) at nm-manager.c:5061
#15 0x00007ffff4b24fec in g_object_unref (_object=0x88a2c0) at gobject.c:3137
#16 0x0000000000444e08 in _nm_singleton_instance_destroy () at NetworkManagerUtils.c:138
#17 0x00007ffff7de97b7 in _dl_fini () at dl-fini.c:252
#18 0x00007ffff4444778 in __run_exit_handlers (status=status@entry=0, listp=0x7ffff47d0618 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true) at exit.c:82
#19 0x00007ffff44447c5 in __GI_exit (status=status@entry=0) at exit.c:104
#20 0x0000000000445b80 in main (argc=1, argv=0x7fffffffdee8) at main.c:458
(gdb)
This downgrades the following warning down to debug-level.
<warn> Could not get scan request result: GDBus.Error:fi.w1.wpa_supplicant1.Interface.ScanError: Scan request rejected
It seems this ~error~ happens regularly, so warning about it is overly
alarming.
Originally, nm-applet loaded the vpn plugins by passing the filename
to g_module_open(). Thereby, g_module_open() allowed for missing file
extension and tries to complete the name with a system-dependent suffix.
When porting to libnm, we kept that behavior but did more elaborate
checks on the file, like checking owner and permissions.
Change to no longer trying to append the system suffix, but require
an exact path. That is no usability problem, because the plugin path
is specified in the .name files, and we just require them now to be the
full path (including the .so extension).
Note also, that this only affects new, libnm-based vpn plugins, thus there
is no change in behavior for legacy libnm-glib based plugins.
Fixes: eed0d0c58f
This reverts commit 44fee0f6ff.
Bad quoting here. Also, this is not quite the best fix for the issue,
filtering on ACTION=="add" is probably a bit more elegant.
When the DHCPv6 lease received from the server contains multiple
addresses, dhclient generates a new BOUND event for each of
them. Instead of overwriting the previous IP6 configuration for each
BOUND event, we should try to detect if the new configuration belongs
to the same lease and merge its addresses with the existing one in
such case.
This allows NetworkManager to configure multiple addresses on an
interface via DHCPv6.
https://bugzilla.gnome.org/show_bug.cgi?id=681764https://bugzilla.redhat.com/show_bug.cgi?id=1244293
Backport to 1.0.6 the following symbols:
- nm_device_wifi_request_scan_options
- nm_device_wifi_request_scan_options_async
Backported by commit 91c0555afaac57234744f42024d95bde46ba170e
Add 'ssids' option to RequestScan() DBus call allowing scanning multiple SSIDs,
support that in libnm and nmcli. And fix nmcli for connecting to hidden SSIDs.
https://bugzilla.gnome.org/show_bug.cgi?id=752173
'ssid' can repeat when more SSIDs should be scanned, e.g.
$ nmcli dev wifi rescan ssid "hidden cafe" ssid AP12 ssid "my home Wi-Fi"
Bash completion fixed by thaller@redhat.com
GNOME release tooling repacks the bz2 to a xz anyway. This makes it easier for
packagers to use tarballs created with "make dist" in place of distribution
tarballs.
When unexporting an object, we might have a notification
pending. When the notification is finally processed, it
would find no "priv->interfaces" and raise an assertion
"idle_emit_properties_changed: assertion 'signal_id != 0' failed"
https://bugzilla.redhat.com/show_bug.cgi?id=1253326
Fixes: 073991f5a8
