At least with my supplicant, the capability is called
all-upper-case "FAST".
The check used case-insensitive, but that was broken
by a previous change.
Fixes: 9f5f141100
(cherry picked from commit 66ff601ecf)
(cherry picked from commit 1caae3743d)
(cherry picked from commit d0ee773221)
We set a dedicated route to reach the VPN gateway only if the parent
device has a gateway. If the parent device doesn't have a gateway (for
example in case of GSM connections) and the VPN gets the default
route, the VPN gateway will be contacted through the VPN itself, which
obviously doesn't work.
Set up a device route if the parent device doesn't provide a gateway.
https://bugzilla.redhat.com/show_bug.cgi?id=1403660
(cherry picked from commit ae5adc9e21)
(cherry picked from commit 48db5806f3)
This usually indicates that the driver missed beacons from the AP, due to driver bugs
or faulty power-save management. It doesn't mean that the PSK is wrong.
(cherry picked from commit 0c5aa6e48b)
A D-Bus signal is asynchronous and it can happen that nm-dhcp-helper
emits the "Event" signal before the server is able to register a handler:
NM_DHCP_HELPER=/usr/libexec/nm-dhcp-helper
nmcli general logging level TRACE
for i in `seq 1 500`; do $NM_DHCP_HELPER & done
journalctl -u NetworkManager --since '1 min ago' | grep "didn't have associated interface" | wc -l
499
Avoid that, by calling the synchronous D-Bus method "Notify".
Interestingly, this race seem to exist since 2007.
Actually, we called g_dbus_connection_signal_subscribe() from inside
GDBusServer:new-connection signal. So it is not clear how such a race
could exist. I was not able to reproduce it by putting a sleep
before g_dbus_connection_signal_subscribe(). On the other hand, there
is bug rh#1372854 and above reproducer which strongly indicates that
events can be lost under certain circumstances.
Now we instead g_dbus_connection_register_object() from the
new-connection signal. According to my tests there was no more race
as also backed by glib's documentation. Still, keep a simple retry-loop
in nm-dhcp-helper just to be sure.
https://bugzilla.redhat.com/show_bug.cgi?id=1372854https://bugzilla.redhat.com/show_bug.cgi?id=1373276
(cherry picked from commit 2856a658b3)
Don't exit(1) from fatal_error() because that skips destroying
local variables in main(). Just return regularly.
(cherry picked from commit bb489163db)
It's not "signal-handles", as it currently tracks the registration ID of
type int. Rename it, it is effectively the list of connections that we
track.
(cherry picked from commit 2dd3a5245f)
When going to sleep, we unmanage devices setting the unmanaged flags
immediately but delaying the state transition (because we do it from
another state transition). The signal handler can be executed after
the wake and, especially, after we have already re-managed the device,
making the device unmanaged again.
Detect such situation and force the state to UNMANAGED (which will
also clear any pending state change), so that later we manage the
device again and it will try to activate any available connection.
Fixes: 81ea812362https://bugzilla.redhat.com/show_bug.cgi?id=1382526
(cherry picked from commit 5f1e36e026)
The @assoc_cancellable was never initialized and thus ineffective; fix
this.
Furthermore, we only cancel it in nm_supplicant_interface_disconnect()
as we expect that clients call the function before destroying the
interface. Don't assume this and also cancel it in dispose().
https://bugzilla.redhat.com/show_bug.cgi?id=1383628
(cherry picked from commit 0539725aef)
(cherry picked from commit 82b953d707)
There can be multiple PPP connections active, each with its own PPP
manager.
Fixes: c1dd3b6eed
(cherry picked from commit bc26f94d1e)
(cherry picked from commit dbacb9ae09)
Depending on how arguments are passed to the called function,
this could lead to a crash.
Maybe not on 32 bit machines where the size of the pointer is
the size of an int.
Maybe not on x86_64, where the arguments are passed in registers.
Fixes: b88c309167
(cherry picked from commit 548a5440e9)
(cherry picked from commit cbfdb72db2)
Some TTY drivers or devices appear to ignore port speed and always
report zero. Technically this means the port is hung up and control
lines should be disconnected, but with USB devices many of the serial
port attributes are meaningless and ignored by some devices.
pppd requires the port's speed to be greater than zero, and will
exit immediately when that is not the case, even though these
modems will work fine. Passing an explicit speed to pppd in this
case works around the issue, as pppd attempts to set that speed
on the port and doesn't actually care if that operation fails.
https://bugzilla.redhat.com/show_bug.cgi?id=1281731
(cherry picked from commit 01de14b1ddcd011ebc2f4676e5950b9ec890c698)
The 'device-added' and 'device-removed' signals indicate when the
value of the 'Devices' property changes. The property only returns
realized devices and so if a device unrealizes we should emit the
removed signal for it.
Fixes: 5da37a129chttps://bugzilla.gnome.org/show_bug.cgi?id=771324
(cherry picked from commit cdedd2b53e)
Before switching to gdbus (before 1.2.0), NetworkManager used dbus-glib.
Most objects in the D-Bus API with properties had a signal
NetworkManager-specific "PropertiesChanged" signal. Nowadays, this way of
handling of property changes is deprecated for the common "PropertiesChanged"
signal on the "org.freedesktop.DBus.Properties" interface.
There were a few pecularities in 1.0.0 and earlier:
(1) Due to the implementation with dbus-glib, a property-changed
signal was emitted on *all* interfaces. For example:
- a change on a NMDeviceVeth of "NMDeviceEthernet.HwAddress" would be
emitted both for the interfaces "fdo.NM.Device.Ethernet" and
"fdo.NM.Device.Veth". Note that NMDeviceVeth is derived from
NMDeviceEthernet and there is no "HwAddress" on veth device.
- a change of "NMVpnConnection.VpnState" was emitted on both
interfaces "fdo.NM.VPN.Connection" and "fdo.NM.Connecion.Active".
Note that NMActiveConnection is the parent type of NMVpnConnection and
only the latter has a property "VpnState".
(2) NMDevice's "fdo.NM.Device" interface doesn't have a "PropertiesChanged"
signal. From (1) follows that all property-changes for this type were instead
invoked with an interface like "fdo.NM.Device.Ethernet" (or multiple
interfaces in case of NMDeviceVeth).
1.2.0 introduced gdbus, which gives us the standard "fdo.DBus.Properties"
signal. However, it made the mistake of not realizing (1), thus instead
of emitting the signal once for each interface, it would pick the first
one in the inheritance tree.
With 1.4.0, a bug from merge commit 844345e caused signals for devices
to be only emitted for the interface "fdo.NM.Device.Statistics", instead
of "fdo.NM.Device.Ethernet" or "fdo.NM.Device.Veth" (or both).
The latter is what bgo#770629 is about and what commit 82e9439 tried to fix.
However, the fix was wrong because it tried to do the theoretically correct
thing of emitting the property-changed signal exactly once for the
interface that actually ontains the property. In addition, it missed that
NMDevice doesn't have a PropertiesChanged signal, which caused signals for
"fdo.NM.Device" to get lost *sigh*.
Now, restore the (broken) behavior of 1.0.0. These old-style property changed
signals are anyway considered deprecated and exist solely to satisfy old clients
and preserve the old API.
Fixes: 63fbfad3705db5901e6a2a6a2fc332da0f0ae4be
https://bugzilla.gnome.org/show_bug.cgi?id=770629https://bugzilla.redhat.com/show_bug.cgi?id=1371920
(cherry picked from commit bef26a2e69)
(cherry picked from commit c29ca9b876)
nm_exported_object_notify() hooks GObject's property-change signal
and searches for the D-Bus interface to which to send the
PropertiesChanged signal.
Then it would enqueue the value encoded as GVariant in pending_notifications.
However, thereby the association between the property that changed and the
interface was lost. So later in idle_emit_properties_changed() it would
just pick the first interface with a properties-changed-id.
That is wrong. pending_notifications must be associated with the D-Bus
interface that we are going to notify. That is, each InterfaceData must
have its own separate list.
This is broken since introducing NMExportedObject and moving to gdbus.
Only now it was discovered as NMDevice itself has two D-Bus interfaces:
"Device" and "Device.Statistics".
Note that the order of the PropertiesChanged in our D-Bus API is not defined
so that later signals can reach the receiver before earlier signals.
Also, multiple change signals for one property may be combined.
That is not changed by this patch and is not considered a bug, but something
that our D-Bus API wrt. PropertiesChanged does not guarantee.
https://bugzilla.gnome.org/show_bug.cgi?id=770629
(cherry picked from commit 82e94390de)
(cherry picked from commit 8d9ea18b3d)
We might be already handling a state change:
Aug 17 05:26:34 dacan.local NetworkManager[618]: (devices/nm-device.c:10982):
_set_state_full: runtime check failed: (priv->in_state_changed == FALSE)
(gdb) bt
#0 0x00007fc218dad643 in g_logv (log_domain=0x7fc21c0db3c3 "NetworkManager", log_level=G_LOG_LEVEL_WARNING, format=<optimized out>, args=args@entry=0x7ffe6f0b30d0) at gmessages.c:1086
#1 0x00007fc218dad7bf in g_log (log_domain=log_domain@entry=0x7fc21c0db3c3 "NetworkManager", log_level=log_level@entry=G_LOG_LEVEL_WARNING, format=format@entry=0x7fc218e1b70f "%s") at gmessages.c:1119
#2 0x00007fc218dadb16 in g_warn_message (domain=domain@entry=0x7fc21c0db3c3 "NetworkManager", file=file@entry=0x7fc21c0d6597 "devices/nm-device.c", line=line@entry=10982, func=func@entry=0x7fc21c0dabf0 <__FUNCTION__.42233> "_set_state_full", warnexpr=warnexpr@entry=0x7fc21c0d95a0 "priv->in_state_changed == FALSE") at gmessages.c:1152
#3 0x00007fc21bf79bd6 in _set_state_full (self=0x7fc21ccd88b0 [NMDeviceEthernet], state=NM_DEVICE_STATE_FAILED, reason=NM_DEVICE_STATE_REASON_DEPENDENCY_FAILED, quitting=0) at devices/nm-device.c:10982
#7 0x00007fc2190bdd9f in <emit signal notify:master on instance 0x7fc21ccd88b0 [NMDeviceEthernet]> (instance=instance@entry=0x7fc21ccd88b0, signal_id=<optimized out>, detail=<optimized out>) at gsignal.c:3439
#4 0x00007fc2190a3908 in g_closure_invoke (closure=0x7fc21cd009e0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7ffe6f0b34b0, invocation_hint=invocation_hint@entry=0x7ffe6f0b3450) at gclosure.c:801
#5 0x00007fc2190b5a1d in signal_emit_unlocked_R (node=node@entry=0x7fc21cb66500, detail=detail@entry=588, instance=instance@entry=0x7fc21ccd88b0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe6f0b34b0)
at gsignal.c:3627
#6 0x00007fc2190bdab1 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe6f0b3640) at gsignal.c:3383
#8 0x00007fc2190a7fd4 in g_object_dispatch_properties_changed (object=0x7fc21ccd88b0 [NMDeviceEthernet], n_pspecs=<optimized out>, pspecs=<optimized out>) at gobject.c:1061
#9 0x00007fc2190aa619 in g_object_notify_by_pspec (pspec=<optimized out>, object=0x7fc21ccd88b0 [NMDeviceEthernet]) at gobject.c:1155
#10 0x00007fc2190aa619 in g_object_notify_by_pspec (object=object@entry=0x7fc21ccd88b0 [NMDeviceEthernet], pspec=<optimized out>) at gobject.c:1264
#11 0x00007fc21bf7de3f in nm_device_master_enslave_slave (prop=PROP_MASTER, obj=0x7fc21ccd88b0 [NMDeviceEthernet]) at devices/nm-device.c:103
#12 0x00007fc21bf7de3f in nm_device_master_enslave_slave (success=1, self=0x7fc21ccd88b0 [NMDeviceEthernet]) at devices/nm-device.c:2757
#13 0x00007fc21bf7de3f in nm_device_master_enslave_slave (self=0x7fc21cd42810 [NMDeviceBond], slave=0x7fc21ccd88b0 [NMDeviceEthernet], connection=<optimized out>) at devices/nm-device.c:1300
#14 0x00007fc2167c8dcc in ffi_call_unix64 () at ../src/x86/unix64.S:76
#15 0x00007fc2167c86f5 in ffi_call (cif=cif@entry=0x7ffe6f0b3a10, fn=<optimized out>, rvalue=0x7ffe6f0b3980, avalue=avalue@entry=0x7ffe6f0b3900) at ../src/x86/ffi64.c:522
#20 0x00007fc2190be2e8 in <emit signal 0x7fc21c0ea3d5 "state-changed" on instance 0x7fc21ccd88b0 [NMDeviceEthernet]> (instance=instance@entry=0x7fc21ccd88b0, detailed_signal=detailed_signal@entry=0x7fc21c0ea3d5 "state-changed") at gsignal.c:3479
#16 0x00007fc2190a4148 in g_cclosure_marshal_generic (closure=0x7fc21cc84de0, return_gvalue=0x0, n_param_values=<optimized out>, param_values=<optimized out>, invocation_hint=<optimized out>, marshal_data=0x0) at gclosure.c:1487
#17 0x00007fc2190a3908 in g_closure_invoke (closure=0x7fc21cc84de0, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7ffe6f0b3c10, invocation_hint=invocation_hint@entry=0x7ffe6f0b3bb0) at gclosure.c:801
#18 0x00007fc2190b5a1d in signal_emit_unlocked_R (node=node@entry=0x7fc21cbeef20, detail=detail@entry=0, instance=instance@entry=0x7fc21ccd88b0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe6f0b3c10) at gsignal.c:3627
#19 0x00007fc2190bdab1 in g_signal_emit_valist (instance=instance@entry=0x7fc21ccd88b0, signal_id=signal_id@entry=112, detail=detail@entry=0, var_args=var_args@entry=0x7ffe6f0b3e48) at gsignal.c:3383
#21 0x00007fc21bf79e3d in _set_state_full (self=self@entry=0x7fc21ccd88b0 [NMDeviceEthernet], state=state@entry=NM_DEVICE_STATE_IP_CONFIG, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE, quitting=quitting@entry=0) at devices/nm-device.c:11123
#22 0x00007fc21bf7a707 in nm_device_state_changed (self=self@entry=0x7fc21ccd88b0 [NMDeviceEthernet], state=state@entry=NM_DEVICE_STATE_IP_CONFIG, reason=reason@entry=NM_DEVICE_STATE_REASON_NONE) at devices/nm-device.c:11308
#23 0x00007fc21bf7e92f in activate_stage3_ip_config_start (self=0x7fc21ccd88b0 [NMDeviceEthernet]) at devices/nm-device.c:6759
#24 0x00007fc21bf68dac in activation_source_handle_cb (self=0x7fc21ccd88b0 [NMDeviceEthernet], family=family@entry=2) at devices/nm-device.c:3627
#25 0x00007fc21bf68e6e in activation_source_handle_cb4 (user_data=<optimized out>) at devices/nm-device.c:3564
#26 0x00007fc218da6d7a in g_main_context_dispatch (context=0x7fc21cb6e000) at gmain.c:3152
#27 0x00007fc218da6d7a in g_main_context_dispatch (context=context@entry=0x7fc21cb6e000) at gmain.c:3767
#28 0x00007fc218da70b8 in g_main_context_iterate (context=0x7fc21cb6e000, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3838
#29 0x00007fc218da738a in g_main_loop_run (loop=0x7fc21cb6c8c0) at gmain.c:4032
#30 0x00007fc21bf4a23e in main (argc=1, argv=0x7ffe6f0b43e8) at main.c:411
(gdb)
https://bugzilla.redhat.com/show_bug.cgi?id=1367702
(cherry picked from commit d070d7f47d)
Fix the following build error:
nm-auth-utils.c: In function ‘nm_auth_chain_add_call’:
nm-auth-utils.c:402:46: error: ‘DBUS_GERROR’ undeclared (first use in this function)
call->chain->error = g_error_new_literal (DBUS_GERROR,
Fixes: 1cf35cb26b
(cherry picked from commit b9e89c918f)
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
(cherry picked from commit eed8fd2e43)
Commit f85941ee91 ("device: don't try to generate ipv6ll address for
disconnected devices") disabled the generation of IPv6 link-local
addresses for disconnected devices to fix a crash. However that broke
the following:
$ ip a f dev eth0
$ systemctl start NetworkManager
$ nmcli d
DEVICE TYPE STATE CONNECTION
eth0 ethernet disconnected eth0
$ ip a a dev eth0 2001::42/64
$ ip a show eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:52:00:61:32:81 brd ff:ff:ff:ff:ff:ff
inet6 2001::42/64 scope global
valid_lft forever preferred_lft forever
(no link-local address)
Revert that change.
Fixes: f85941ee91
(cherry picked from commit 75406d1760)
If the device is disconnected because it can't be assumed due to lack
of IP configuration, don't try to generate an ipv6 link-local address,
as this requires a connection.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 __GI_abort () at abort.c:89
#2 g_assertion_message (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", message=message@entry=0x1e86100 "assertion failed: (connection)") at gtestutils.c:2429
#3 g_assertion_message_expr (domain=domain@entry=0x5f41b4 "NetworkManager", file=file@entry=0x5ef9b5 "devices/nm-device.c", line=line@entry=831,
func=func@entry=0x5f3220 <__FUNCTION__.37383> "nm_device_get_ip_iface_identifier", expr=expr@entry=0x5e65c6 "connection") at gtestutils.c:2452
#4 nm_device_get_ip_iface_identifier (self=self@entry=0x1e612a0, iid=iid@entry=0x7fffce40e3d0, ignore_token=ignore_token@entry=1) at devices/nm-device.c:831
#5 check_and_add_ipv6ll_addr (self=self@entry=0x1e612a0) at devices/nm-device.c:5983
#6 queued_ip6_config_change (user_data=0x1e612a0) at devices/nm-device.c:9489
#7 g_main_dispatch (context=0x1d3e060) at gmain.c:3154
#8 g_main_context_dispatch (context=context@entry=0x1d3e060) at gmain.c:3769
#9 g_main_context_iterate (context=0x1d3e060, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3840
#10 g_main_loop_run (loop=0x1d3ab00) at gmain.c:4034
#11 main (argc=1, argv=0x7fffce40e6a8) at main.c:411
https://bugzilla.redhat.com/show_bug.cgi?id=1351633
(cherry picked from commit f85941ee91)
The dhclient and dhcpcd clients can be destroyed during disposal of
the DHCP manager singleton and at that point the NMDhcpListener
singleton can be already gone. Reference it in the clients.
(cherry picked from commit e5430a182c)
DNS properties should not be copied to parent device's configuration
otherwise they will be applied twice, possibly with two different DNS
priorities.
(cherry picked from commit df48628a48)
Previously we created a new NMIP[46]Config object to replace the
previous one every time the plugin reported a new IP configuration
through the Ip[46]Config signal, but the old configuration was not
removed from the DNS manager and would become stale.
The interaction with DNS manager is handled by NMPolicy, which only
reacts to changes in connection status, so it's not easy to have the
configuration removed from DNS while keeping the connection state
ACTIVATED.
A cleaner solutions is to avoid creating a new IP configuration object
and reuse the existing one if possible. The side effect is that the
D-Bus path of the object will not change, which seems also positive.
https://bugzilla.redhat.com/show_bug.cgi?id=1348901
(cherry picked from commit 641e8b00fe)
If the plugin sends a new configuration when the connection is already
activated the state should not go back to PRE_UP since this causes
dispatcher scripts to run again.
(cherry picked from commit 19133b08da)
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
(cherry picked from commit f2d5c8d7f8)
nl_recv() in libnl3 before version 3.2.15 would return dangling pointers
if nl_recv() fails or has nothing to read [1].
Workaround that by explicitly clearing @buf and @creds.
https://bugzilla.gnome.org/show_bug.cgi?id=767986
[1] 69468517d0
(cherry picked from commit 66715515dc)
When a reverse DNS entry must be added to dnsmasq, instead of
considering IP addresses as classful use the prefix to compute one or
more "in-addr.arpa" according to CIDR rules.
https://bugzilla.gnome.org/show_bug.cgi?id=767174
(cherry picked from commit 4d1e7dc23c)
With
[main]
#dns=
we would see in the log:
dns-mgr: init: dns=(null), rc-manager=symlink
Instead, it should be
dns-mgr: init: dns=default, rc-manager=symlink
Also, we should avoid logging NULL values with "%s", although
glib's printf is fine with that.
(cherry picked from commit bcb88d540e)
Before, we would first check whether the file is immuable before
parsing main.rc-manager setting. That means, if you configured
[main]
dns=default
rc-manager=unmanged
we would still first try to detect whether the file is immutable.
The result of course is only minor, e.g. showing up in logging
as rc-manager=immutable instead of rc-manager=unmanged.
Also, an immutable resolv.conf would suppress a warning about
a bogus rc-manager setting.
Also, when selecting rc-manager=symlink and resolv.conf is a symlink
to an immutable file, we don't actually care about that. The reason is,
that if the link-target is not /var/run/NetworkManager/resolv.conf,
we anyway wouldn't modify the file.
The effect of this change is pretty minor, now in logging you would see:
dns-mgr: init: dns=default, rc-manager=symlink
dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded but don't update /etc/resolv.conf as it points to /some/where/else
instead of
dns-mgr: init: dns=default, rc-manager=immutable
dns-mgr: update-resolv-conf: write internal file /var/run/NetworkManager/resolv.conf succeeded
Which feels slightly more right.
Note that symlinks cannot have file attributes.
(cherry picked from commit 4711867915)
Until before 1.2.0, NetworkManager would always write resolv.conf as file, but
if /etc/resolv.conf was a symlink, it would follow the link instead of
replacing it with a file ([1], [2]).
With 1.2.0, we initially dropped that behavior and added a new 'rc-manager=none'
which writes resolv.conf to /var/run/NetworkManager and symlinks resolv.conf [3].
In case resolv.conf being already a symlink to another target, it would
not be replaced [4].
Later, we added 'rc-manager=file', which always writes /etc/resolv.conf as
file [5].
With 1.4.0, we will rename 'rc-manager=none' to 'rc-manager=symlink' [6].
This commit now fixes 'rc-manager=file' to restores the pre-1.2 behavior
and follow symlinks.
[1] 5761e328b8
[2] https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/324233
[3] 4805be2ed2
[4] 583568e12f
[5] 288799713d
[6] cd6a469668https://github.com/NetworkManager/NetworkManager/pull/7
(cherry picked from commit 718fd22436)
