Since commit ebe3320e62,
nm_ap_new_from_properties() will always return an
AP with BSSID set. Restore the assertion during
try_fill_ssid_for_hidden_ap().
This reverts commit e0e043ef39.
(cherry picked from commit d5373959f9)
Otherwise we'd hit an assert and rightly so!
Program received signal SIGTRAP, Trace/breakpoint trap.
g_logv (log_domain=0x5555556b2f80 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffcd10) at gmessages.c:1046
1046 g_private_set (&g_log_depth, GUINT_TO_POINTER (depth));
(gdb) bt
#0 g_logv (log_domain=0x5555556b2f80 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7fffffffcd10) at gmessages.c:1046
#1 0x00007ffff4a4ea3f in g_log (log_domain=log_domain@entry=0x5555556b2f80 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7ffff4ac1e4c "%s") at gmessages.c:1079
#2 0x00007ffff4a4ed56 in g_warn_message (domain=domain@entry=0x5555556b2f80 "NetworkManager", file=file@entry=0x5555556aca93 "devices/nm-device.c", line=line@entry=1101,
func=func@entry=0x5555556b22e0 <__FUNCTION__.35443> "nm_device_release_one_slave", warnexpr=warnexpr@entry=0x0) at gmessages.c:1112
#3 0x00005555555ba80a in nm_device_release_one_slave (self=self@entry=0x5555559ec4c0, slave=slave@entry=0x5555559f7800, configure=configure@entry=1, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE)
at devices/nm-device.c:1101
#4 0x00005555555c264b in slave_state_changed (slave=0x5555559f7800, slave_new_state=NM_DEVICE_STATE_FAILED, slave_old_state=NM_DEVICE_STATE_IP_CONFIG, reason=NM_DEVICE_STATE_REASON_NONE, self=0x5555559ec4c0)
at devices/nm-device.c:1700
#5 0x00007ffff339cdac in ffi_call_unix64 () at ../src/x86/unix64.S:76
#6 0x00007ffff339c6d5 in ffi_call (cif=cif@entry=0x7fffffffd1c0, fn=<optimized out>, rvalue=0x7fffffffd130, avalue=avalue@entry=0x7fffffffd0b0) at ../src/x86/ffi64.c:522
#7 0x00007ffff4d45678 in g_cclosure_marshal_generic (closure=0x5555559b0160, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0)
at gclosure.c:1454
#8 0x00007ffff4d44e38 in g_closure_invoke (closure=0x5555559b0160, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7fffffffd3c0,
invocation_hint=invocation_hint@entry=0x7fffffffd360) at gclosure.c:768
#9 0x00007ffff4d5675d in signal_emit_unlocked_R (node=node@entry=0x55555598a6f0, detail=detail@entry=0, instance=instance@entry=0x5555559f7800, emission_return=emission_return@entry=0x0,
instance_and_params=instance_and_params@entry=0x7fffffffd3c0) at gsignal.c:3553
#10 0x00007ffff4d5e4c1 in g_signal_emit_valist (instance=instance@entry=0x5555559f7800, signal_id=signal_id@entry=72, detail=detail@entry=0, var_args=var_args@entry=0x7fffffffd5f8) at gsignal.c:3309
#11 0x00007ffff4d5ecc8 in g_signal_emit_by_name (instance=instance@entry=0x5555559f7800, detailed_signal=detailed_signal@entry=0x5555556c0405 "state-changed") at gsignal.c:3405
#12 0x00005555555bd0e0 in _set_state_full (self=self@entry=0x5555559f7800, state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE, quitting=quitting@entry=0)
at devices/nm-device.c:8580
#13 0x00005555555be0e7 in nm_device_state_changed (self=self@entry=0x5555559f7800, state=state@entry=NM_DEVICE_STATE_FAILED, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:8741
#14 0x00005555555c0a45 in queued_set_state (user_data=<optimized out>) at devices/nm-device.c:8765
#15 0x00007ffff4a4779a in g_main_dispatch (context=0x5555559433c0) at gmain.c:3109
#16 g_main_context_dispatch (context=context@entry=0x5555559433c0) at gmain.c:3708
#17 0x00007ffff4a47ae8 in g_main_context_iterate (context=0x5555559433c0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3779
#18 0x00007ffff4a47dba in g_main_loop_run (loop=0x555555943480) at gmain.c:3973
#19 0x000055555559713d in main (argc=1, argv=0x7fffffffdb78) at main.c:512
(gdb)
(cherry picked from commit aa05d25bef)
The library and the include paths are dragged in with DBUS_CFLAGS but we need
more; especially the GLIB_VERSION_{MIN/MAX}_REQUIRED macros. Otherwise we get
deprecation warnings.
No master commit, since this was fixed as a side-effect of the GDBus merge.
Device activation normally fails during one of the stages and in that
case the activation chain is implicitly interrupted.
But in some cases the device fails for external events (as a failure
of master connection) while the activation sequence is still running
and so we need to ensure that any pending activation source gets
cleared upon entering the failed state.
https://bugzilla.redhat.com/show_bug.cgi?id=1270814
(cherry picked from commit c8e2339091)
Because Bluez5 dropped DUN support, NM must do that manually which
includes emulating the "connected" property for Bluetooth devices when
DUN is used. It does this by setting priv->connected = TRUE in
nm_bluez_device_connect_finish().
But for PAN, when NM does process the 'connected' property change
notification, priv->connected is already TRUE and
_take_variant_property_connected() does nothing. Hence the
corresponding GObject property notification is not emitted,
nm-device-bt.c::check_connect_continue() will never return success, and
the activation times out.
To fix this, ensure that GObject notifications are emitted when the
device is connected, even if emulated internally.
https://mail.gnome.org/archives/networkmanager-list/2015-October/msg00053.htmlhttps://bugzilla.redhat.com/show_bug.cgi?id=1255284
(cherry picked from commit 0e3086e8b8)
Commit 285ee1fda2 added NM_UNMANAGED_PLATFORM_INIT
flag marking platform uninitialized devices. The flags is set by
NM_DEVICE_PLATFORM_DEVICE property and on link changes. However, for virtual
devices, the platform device property was not set at NM device construction time
and link change event happened even before. That resulted in the device having
platform_link_initialized=FALSE and thus it was left unmanaged.
Make the change for other software devices too.
https://bugzilla.redhat.com/show_bug.cgi?id=1273879
Add a new 'ignore' option to NMSettingWired.wake-on-lan which disables
management of wake-on-lan by NetworkManager (i.e. the pre-existing
option will not be touched). Also, change the default behavior to be
'ignore' instead of 'disabled'.
https://bugzilla.gnome.org/show_bug.cgi?id=755182
(cherry picked from commit e587dcb16e)
The unmanaged-flag NM_UNMANAGED_EXTERNAL_DOWN is initially set during
nm_device_finish_init(). But it was only set if the device was down at
that point.
If due to a race the platform device was not yet initialized, a later
initialization in device_link_changed() would clear NM_UNMANAGED_PLATFORM_INIT.
If the device is not external-down (because it was already up during
nm_device_finish_init()), the device will be managed right away with
reason NM_DEVICE_STATE_REASON_NOW_MANAGED.
Together with commit e29ab54335, this
is a race that causes a failure to assume the external-down device.
https://bugzilla.redhat.com/show_bug.cgi?id=1269199
(cherry picked from commit 120847c8a3)
When a VLAN has a bond as parent device the MAC address of the bond
may change when other devices are enslaved and then the VLAN would
have a MAC which is different from parent's one.
Let the VLAN device listen for changes in hw-address property of
parent and update its MAC address accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=1264322
(cherry picked from commit e6d7fee5a6)
Executing:
# brctl addbr lbr0
# ip addr add 10.1.1.1/24 dev lbr0
# ip link set lbr0 up
can result in a race so that NetworkManager would manage the device
(and clear the IP addresses).
It happens, when NetworkManager first receives platform signals that
the device is already up:
signal: link changed: 11: lbr0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 bridge* not-init addrgenmode eui64 addr D2:A1:B4:17:18:F2 driver bridge
Note that the device is still unknown via udev (not-init). The
unmanaged-state NM_UNMANAGED_EXTERNAL_DOWN gets cleared, but the
device still stays unmanaged.
Only afterwards the device is known in udev:
signal: link changed: 11: lbr0 <UP,LOWER_UP;broadcast,multicast,up,running,lowerup> mtu 1500 arp 1 bridge* init addrgenmode eui64 addr D2:A1:B4:17:18:F2 driver bridge
At this point, we also clear NM_UNMANAGED_PLATFORM_INIT, making
the device managed with reason NM_DEVICE_STATE_REASON_NOW_MANAGED.
That results in managing the external device.
Fix that by only clearing NM_UNMANAGED_EXTERNAL_DOWN after the device
is no longer NM_UNMANAGED_PLATFORM_INIT.
https://bugzilla.redhat.com/show_bug.cgi?id=1269199
(cherry picked from commit e29ab54335)
Don't handle master-ready at the beginning of stage2, but instead while
scheduling (and then possibly delaying the scheduling of stage2).
This seems more idiomatic:
When inside a stage and your part is done: call schedule-next-stage.
That is, always schedule the next stage, not the current one.
schedule-next-stage then might delay to really scheduling until the
device is ready for the next state.
Fixes: 85ac903bb8
(cherry picked from commit 7bbc090387)
During stage2, if the slave detected that it would need to wait for
the master, it would return FALSE (which removes the g-idle-handler).
However, it would not clear the activation-source, so later, when
the master becomes ready, its attempt to schedule stage2 again would
result in an error-log and the idle-handler would not be scheduled
again.
Fixes: 85ac903bb8https://bugzilla.redhat.com/show_bug.cgi?id=1268797https://bugzilla.redhat.com/show_bug.cgi?id=1183444
(cherry picked from commit c5210b322d)
When activating for example a team device which is to be enslaved to a
bridge, nm_device_activate_stage1_device_prepare() will postpone
stage 2.
In that case, we didn't register the "master-ready" of the team
device and thus never progressed the slave from stage2.
Reproduce:
# nmcli connection delete t-br0
# nmcli connection delete t-team0
nmcli connection add type bridge con-name t-br0 autoconnect no ifname i-br0 ip4 192.168.177.100/24 gw4 192.168.177.1
nmcli connection add type team con-name t-team0 autoconnect no ifname i-team0
nmcli connection modify id t-team0 connection.master i-br0 connection.slave-type bridge
nmcli connection up t-team0
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
(cherry picked from commit 7bf10a75db)
Depending on the network and the values of the 'dad_transmits' and
'retrans_timeout_ms' sysctls, DAD for the IPv6LL address can take
quite a while. Obviously there must be some upper bound on the
timeout, but 5 seconds seems a bit low. In this case it was observed
to be ~12 seconds but the sysctl values are unknown. In any case,
we can't predict the network/config so being a bit more lenient here
makes sense.
https://bugzilla.redhat.com/show_bug.cgi?id=1101809
(cherry picked from commit 5b374a4a9f)
If SIM in a modem is locked, ModemManager can't initialize SupportedIpFamilies
and NetworkManager will set the property to 0. ModemManager then updates the
property after the modem is unlocked, but NetworkManager did not watch changes
to the property. And that resulted in a connection failure:
(ttyUSB1): Failed to connect 'O2 Internet': Connection requested IPv4 but IPv4 is unsuported by the modem.
(ttyUSB1): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28]
https://bugzilla.redhat.com/show_bug.cgi?id=1263959
(cherry picked from commit eecb4c46cc)
NetworkManager set wpa_supplicant's fragment_size option to 1300. But if MTU
was lower, wpa_supplicant failed with "l2_packet_send - sendto: Message too
long" due to fragmentation of EAP-TLS or EAP-PEAP packets.
Actually, MTU has to be 14 bytes bigger than the "fragment_size" parameter.
Ideally, wpa_supplicant would take MTU in the account and adjust the
fragmentation limit accordingly. See discussion in
http://lists.shmoo.com/pipermail/hostap/2015-August/033546.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=755145
(cherry picked from commit 94bbe7465f)
When a new link is detected, NM tries to generate a default "Wired
connection" in nm_settings_device_added(), but if the link has not
been initialized by udev yet the function returns early because
priv->unmanaged_flags = UNMANAGED_PLATFORM_INIT.
To be sure that a default connection is created is such situation, we
need to call again nm_settings_device_added() after link
initialization.
https://bugzilla.redhat.com/show_bug.cgi?id=1254089
(cherry picked from commit b3b0b46250)
If at the moment when spawning nm-iface-helper dhcp4/slaac
did not yet complete, we would not enable it.
That is wrong. If the connection indicates to use dhcp4/slaac,
it should be used by nm-iface-helper without considering the
current state on the device.
https://bugzilla.redhat.com/show_bug.cgi?id=1260243
(cherry picked from commit b0815813fa)
If DHCP fails for an assumed connection, NetworkManager would
transition the device to the FAILED and then to the ACTIVATED state
(because it is assumed); hence if the DHCP server goes temporarily
down the device will go into a permanent state without IP
configuration.
Fix this and try DHCP again after some time when the connection
is an assumed one.
https://bugzilla.redhat.com/show_bug.cgi?id=1246496
This would cause the ip_vti0 generic device (that appears upon insertion of
ip_vti module during libreswan ipsec stack init) to go managed and brought UP.
Without addresses assigned the device would cause all the VPN traffic to
disappear in the oblivion.
(cherry picked from commit 1c46ddf196)
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
(cherry picked from commit 1d6e8e8da7)
Don't disconnect the device when the DHCP renewal fails and there are
already configured static IP addresses on the device. Instead, keep
the device up and try DHCP again after some time.
https://bugzilla.redhat.com/show_bug.cgi?id=1168388
(cherry picked from commit abc96ecdfd)
The parent of a link (IFLA_LINK) can be in another network namespace and
thus invisible to NM.
This requires the netlink attribute IFLA_LINK_NETNSID which is supported
by recent versions of kernel and libnl.
In this case, set the parent field to NM_PLATFORM_LINK_OTHER_NETNS
and properly handle this special case.
(cherry picked from commit 790a0713d2)
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.
(cherry picked from commit ad7cdfc766)
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
(cherry picked from commit b557f91a1b)
