Software devices must report the NM_DEVICE_CAP_IS_SOFTWARE capability
in order to be properly activated. Add the flag to NMDeviceTun and
NMDeviceVxlan.
https://bugzilla.gnome.org/show_bug.cgi?id=767846
It's possible for wpa_supplicant to transition to INACTIVE
state with an outstanding requested_scan pending. This can
lead to a stall condition where scanning no longer occurs.
[thaller@redhat.com: added break statement to avoid fall-through]
https://mail.gnome.org/archives/networkmanager-list/2016-June/msg00116.html
For changing the hardware address, we must bring the device down. When doing
that, IP addressing is lost and it must be re-configured after bringing the
device up again.
We already do something similar in device_link_changed(), but that might
not be sufficient, because device_link_changed() is run on an idle
handler, thus, while changing the hardware address it has no chance to
run (or notice that the device was shortly down).
https://bugzilla.redhat.com/show_bug.cgi?id=1309899
Add a new "Config" property to the D-Bus interface for team devices
and show its value through "nmcli device show". The property contains
the full JSON configuration from teamd for the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1310435
Instead of accessing the singleton getter nm_settings_get(), obtain
the settings instance from the device instance itself via
nm_device_get_settings().
Currently NM proceeds with the activation of a device just after the
IPv6 configuration is applied. Server applications will bind to IPv6
addresses as soon as NM signals the presence of network connectivity,
but since the addresses are still tentative the bind will fail. There
are a couple of solutions to this.
Linux kernel supports "optimistic DAD", which is a modification of
Neighbor Discovery and SLAAC processes that allows addresses to be
used (under certain contraints) while kernel is performing DAD on
them. However it is not feasible to let NM enable optimistic DAD for
the devices it controls for the following reasons:
- it is not guaranteed to be always available since it can be turned
off at compile time
- RFC 4429 states that it should not be used for manually entered
addresses
- it works only with autoconf addresses generated by kernel
Therefore, use a different approach and handle this in NM by waiting
that the kernel completes DAD before continuing activation. We build a
list of addresses that are tentative just after the new configuration
is applied and then we asynchronously wait a platform address-change
event where all NM-configured addresses become non-tentative.
A similar solution has been adopted also by other network managing
tools:
https://anonscm.debian.org/cgit/collab-maint/ifupdown.git/commit/?id=ec357a5d6cb5fa8b0004c727d7cc48253c59eb0f8012cd3919https://bugzilla.redhat.com/show_bug.cgi?id=1243958
A large part of "nm-test-utils.h" is only relevant for tests inside "src/"
directory, as they are helpers related to NetworkManager core part.
Split this part out of "nm-test-utils.h" header.
- make NMAccessPoint and NMAccessPointClass internal structs. This means,
they cannot be subclassed anymore, but we also don't want that.
- This way, we can safely embed the private data directly in the now
private access-point instance.
- change type of boolean fields from gboolean to bool.
- some whitespace fixes
(gdb) bt
#0 0x00007ffff4d9e075 in g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x-1, fundamental_type=fundamental_type@entry=80) at gtype.c:4030
#1 0x00007ffff4d7e447 in g_object_unref (_object=0xffffffffffffffff) at gobject.c:3076
#2 0x00007fffe89cdfa8 in disconnect_context_complete (ctx=ctx@entry=0x555555b4c680) at nm-modem-broadband.c:1062
#3 0x00007fffe89cf6e5 in disconnect (modem=<optimized out>, warn=0, cancellable=0x0, callback=0x0, user_data=0x0) at nm-modem-broadband.c:1126
#4 0x00007fffe89d24cd in nm_modem_deactivate (self=0x555555aba1b0 [NMModemBroadband], device=device@entry=0x555555ab8c20 [NMDeviceModem]) at nm-modem.c:1164
#5 0x00007fffdbd73022 in deactivate (device=0x555555ab8c20 [NMDeviceModem]) at nm-device-modem.c:455
#6 0x00005555555e087b in nm_device_cleanup (self=self@entry=0x555555ab8c20 [NMDeviceModem], reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_MANAGED, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE)
at devices/nm-device.c:10392
#7 0x00005555555e0ffd in _set_state_full (self=self@entry=0x555555ab8c20 [NMDeviceModem], state=state@entry=NM_DEVICE_STATE_UNAVAILABLE, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_MANAGED, quitting=quitting@entry=0) at devices/nm-device.c:10804
#8 0x00005555555e1a16 in nm_device_state_changed (self=self@entry=0x555555ab8c20 [NMDeviceModem], state=state@entry=NM_DEVICE_STATE_UNAVAILABLE, reason=reason@entry=NM_DEVICE_STATE_REASON_NOW_MANAGED)
at devices/nm-device.c:11029
Fixes: 21b50c59ce
Fall back to system default value for ipvx.dns-priority when it's zero
in the setting. For VPNs the default value is 50; for other
connections is 100, but it depends also on the content of
[connection*] sections in NetworkManager.conf.
