We'd be able to do so for already existing devices, but not for devices that
are added afterwards, since gudev is hardwired not to listen for events from
kernel.
Mount a private sysfs instance. Otherwise gudev sees the devices from the
parent netns as opposed to our netns.
We do, however need a writable /sys/devices subtree for testing the bridge
code. There doesn't seem to be any other way to get a writable subtree of a
read-only filesystem than remounting it with no parameters after the initial
mount. We use this to get a writable sysfs instance and then bindmount it so
that it fits properly in the sysfs hierarchy.
Co-Authored-By: Thomas Haller <thaller@redhat.com>
It could be that the device was removed and the default route manager holds the
last reference:
Breakpoint 1, dispose (object=0x90e710 [NMDeviceTun]) at devices/nm-device.c:8588
8588 NMDevice *self = NM_DEVICE (object);
(gdb) bt
#0 0x000000000045d24e in dispose (object=0x90e710 [NMDeviceTun]) at devices/nm-device.c:8588
#1 0x00007ffff4d29b7c in g_object_unref (_object=0x90e710) at gobject.c:3133
#2 0x00000000004b0a61 in _entry_at_idx_remove (entry=<optimized out>) at nm-default-route-manager.c:192
#3 0x00000000004b0a61 in _entry_at_idx_remove (vtable=<optimized out>, self=<optimized out>, entry_idx=<optimized out>) at nm-default-route-manager.c:638
#4 0x00000000004adb51 in _ipx_update_default_route (vtable=0x7b1850 <vtable_ip6>, self=0x7da610 [NMDefaultRouteManager], source=<optimized out>) at nm-default-route-manager.c:814
#5 0x0000000000459ccb in nm_device_set_ip6_config (self=0x90e710 [NMDeviceTun], new_config=<optimized out>, commit=<optimized out>, reason=<optimized out>) at devices/nm-device.c:6213
#6 0x0000000000450c92 in ip6_config_merge_and_apply (self=0x90e710 [NMDeviceTun], commit=0, out_reason=0x0) at devices/nm-device.c:3670
#7 0x0000000000452d06 in update_ip_config (self=0x90e710 [NMDeviceTun], initial=<optimized out>) at devices/nm-device.c:6915
#8 0x000000000046253e in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6945
#9 0x00007ffff4a257fb in g_main_context_dispatch (context=0x7ca3e0) at gmain.c:3111
#10 0x00007ffff4a257fb in g_main_context_dispatch (context=context@entry=0x7ca3e0) at gmain.c:3710
#11 0x00007ffff4a25b98 in g_main_context_iterate (context=0x7ca3e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#12 0x00007ffff4a25ec2 in g_main_loop_run (loop=0x7ca4a0) at gmain.c:3975
#13 0x0000000000444bbe in main (argc=<optimized out>, argv=<optimized out>) at main.c:486
(gdb)
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x7ffff4d4f164 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffd5b0) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 0x00007ffff4a2c970 in g_logv (log_domain=0x7ffff4d4f164 "GLib-GObject", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffd5b0) at gmessages.c:1046
#1 0x00007ffff4a2cbaf in g_log (log_domain=log_domain@entry=0x7ffff4d4f164 "GLib-GObject", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff4d563b0 "invalid unclassed pointer in cast to '%s'") at gmessages.c:1079
#2 0x00007ffff4d481f9 in g_type_check_instance_cast (type_instance=0x90e710, iface_type=<optimized out>) at gtype.c:4030
#3 0x0000000000459ceb in nm_device_set_ip6_config (self=0x90e710, new_config=<optimized out>, commit=<optimized out>, reason=0x0) at devices/nm-device.c:6217
#4 0x0000000000450c92 in ip6_config_merge_and_apply (self=0x90e710, commit=0, out_reason=0x0) at devices/nm-device.c:3670
#5 0x0000000000452d06 in update_ip_config (self=0x90e710, initial=<optimized out>) at devices/nm-device.c:6915
#6 0x000000000046253e in queued_ip_config_change (user_data=<optimized out>) at devices/nm-device.c:6945
#7 0x00007ffff4a257fb in g_main_context_dispatch (context=0x7ca3e0) at gmain.c:3111
#8 0x00007ffff4a257fb in g_main_context_dispatch (context=context@entry=0x7ca3e0) at gmain.c:3710
#9 0x00007ffff4a25b98 in g_main_context_iterate (context=0x7ca3e0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#10 0x00007ffff4a25ec2 in g_main_loop_run (loop=0x7ca4a0) at gmain.c:3975
#11 0x0000000000444bbe in main (argc=<optimized out>, argv=<optimized out>) at main.c:486
(gdb)
https://bugzilla.gnome.org/show_bug.cgi?id=748193
NM always prepends the list of DNS domains received through DHCP to
the search list in /etc/resolv.conf, overriding the DHCP-supplied DNS
domain search order. This behavior is not entirely correct since it
changes the search order provided by system administrators.
We cannot simply avoid adding the DNS domain list to the search list
because this would break some configurations that rely on the 'domain'
option to deliver the search list.
This patch modifies the behavior of DNS manager to:
- insert the DHCP-provided 'domain' at the end of 'searches' option
so that 'searches' is always preferred
- ignore 'domain' if 'searches' option exists and 'domain' is a
single domain
https://bugzilla.gnome.org/show_bug.cgi?id=748900
g_dbus_proxy_get_cached_property_names() function can return NULL.
Program received signal SIGSEGV, Segmentation fault.
on_bss_proxy_acquired (proxy=0x7fffe4003880 [GDBusProxy], result=0x895490, user_data=<optimized out>) at supplicant-manager/nm-supplicant-interface.c:159
159 while (*iter) {
(gdb) bt
#0 0x000000000048fac7 in on_bss_proxy_acquired (proxy=0x7fffe4003880 [GDBusProxy], result=0x895490, user_data=<optimized out>)
at supplicant-manager/nm-supplicant-interface.c:159
#1 0x0000003bf84728b7 in g_simple_async_result_complete (simple=0x895490 [GSimpleAsyncResult]) at gsimpleasyncresult.c:763
#2 0x0000003bf8472919 in complete_in_idle_cb (data=<optimized out>) at gsimpleasyncresult.c:775
#3 0x0000003bf5c497fb in g_main_context_dispatch (context=0x7d6420) at gmain.c:3111
#4 0x0000003bf5c497fb in g_main_context_dispatch (context=context@entry=0x7d6420) at gmain.c:3710
#5 0x0000003bf5c49b98 in g_main_context_iterate (context=0x7d6420, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3781
#6 0x0000003bf5c49ec2 in g_main_loop_run (loop=0x7d64e0) at gmain.c:3975
#7 0x00000000004349d6 in main (argc=1, argv=0x7fffffffe598) at main.c:486
Instead of hacky stuff in the Manager, let plugins themselves indicate
which links should be ignored (because they are really child links that
are controlled by a different device that the plugin handles).
Ethernet, WiFi, and VLAN used the same implementation for initial address.
Ethernet and WiFi used the same implementation (and duplicated code) for
permanent MAC address, plus they both used ethtool in what should be
generic code, which is better done in the platform.
Instead of having a bunch of logic in the Manager for determining the
VLAN and Infiniband virtual interface names, move the type-specific
logic into the plugins themselves.
Instead of looping over all plugins and asking each plugin whether it
can handle a link or a connection, have them advertise the link and
connection types they support, and use that when creating new devices.
For existing devices, depending on the order that netlink sends interfaces to
us, the parent may be found after the VLAN interface and not be available when
the VLAN interface is constructed. Instead of failing construction, when a
NMDeviceVlan has no parent keep it unavailable for activation. Then have
the Manager notify existing devices when a new device is found, and let
NMDeviceVlan find the parent later and become available via that mechanism.
This doesn't apply to VLANs created by NM itself, because the kernel requires
a parent ifindex when creating a VLAN device. Thus this fix only applies to
VLANs created outside NetworkManager, or existing when NM starts up.
beb18050 made this code run for all devices instead of just ethernet
devices, which means any kind of connection gets compared to any
device. But only compatible connections should be considered.
NM never removes the current AP from the AP list, to prevent NM from
indicating that it's connected, but to nothing. But the supplicant
can remove that AP from its list at any time (out of range, turned off,
etc), leading to a priv->current_ap that is no longer known to the
supplicant but still exists in the NM AP list. Since the supplicant
has forgotten it, NM will never receive a removal signal for it.
To ensure that a supplicant-forgotten priv->current_ap is removed
from the NM AP list when priv->current_ap is cleared or changed, mark
any AP removed by the supplicant as 'fake'. It will then always be
removed in set_current_ap() and not linger in the AP list forever like
a zombie.
Instead of tricky logic to merge APs and age them, just tell the
supplicant what our aging parameters are, and rely on it to handle
removal from the list. Notable behavioral changes are:
* APs will now be removed when they haven't been seen for two
consecutive scans in which they would have been included. This
means that when the scan interval is short, out-of-range APs will
be removed much more quickly than the previous 360 seconds.
* APs now live at most 250 seconds (twice our longest scan interval)
instead of the previous 360 seconds.
* The problem with wpa_supplicant < 2.3 not notifying that a BSS has
been seen in the scan if none of its properties actually changed is
now avoided, because an AP is only removed when the supplicant removes it
In general these changes should make the scan list more responsive, at
the cost of slightly more instability in the list due to the unreliability
of WiFi scanning. But it also removes a layer of complexity and
abstraction from NetworkManager, pushing the scan results list closer
to that which the hardware reports.
The VPN connection requests secrets a few times; first it retrieves
only system-owned secrets to see if they are sufficient (and thus
doesn't need to bother the user), then it retrieves existing agent
owned secrets (so the user doesn't get a popup), then finally if
those aren't sufficient it asks the user interactively.
But if there was some error retrieving system secrets, or if there
weren't any system secrets at all, don't fail the VPN connection.
Just go on and ask the user for the secrets.
Now on SIGHUP, when reloading NetworkManager configuration, also reload
the ignore-carrier flag.
While a device is activated, the reload is ignored until the device
deactivates.
Maybe it would be simpler just not to cache ignore_carrer and let it
take effect immediately. But not caching ignore_carrer has the
additional downside that every call to is_available must check the
specs -- which in sum is potentially expensive for something that
almost never changes.
https://bugzilla.gnome.org/show_bug.cgi?id=748050
