When a Wi-Fi is switched to AP mode, NMDeviceWifi forgets the AP scan list.
Later, when the device goes back to normal managed mode, the device was not
able to acquire the AP list again (for a long time), because the list is only
populated when a new BSS is signalled. And that could take very long or never
happen as the supplicant would have to lost the BSS and announce it later.
Fix the problem by announcing known BSSs as a response to ScanDone signal.
Testcase:
$ nmcli con add type wifi ifname wlan0 con-name my-wifi-ap autoconnect off ssid MYSSID
$ nmcli con modify my-wifi-ap wifi.mode ap ipv4.method shared
$ nmcli con up my-wifi-ap
$ nmcli con down my-wifi-ap
$ nmcli device wifi list
https://bugzilla.redhat.com/show_bug.cgi?id=1267327
Modify the DNS manager to use the static global DNS configuration when
available. In addition, change DNS plugins interface to accept a new
argument for global configuration and add support for this new
parameter to the dnsmasq plugin.
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
The 9b79e6c73 commit moved setting of the MTU from IP4Config to NMDevice, but
VPN connections don't have a NMDevice instance (yet). Set the MTU also from the
VPN connection. Also, copying of the MTU to the IP4Config is no longer needed
as the ip4_config_commit no longer sets the MTU.
Fixes: 9b79e6c732ffb2fb105647c1465070d36a6cc180
https://bugzilla.gnome.org/show_bug.cgi?id=754781
For certain types of connection as PPP and WWAN the IP interface is
created during stage3 (IP config) but we are setting the firewall zone
at the beginning of stage3 and thus the zone is only set on the
underlying interface.
Add a check at the start of IP check phase to ensure that the firewall
zone is set again if the device interface is different from IP
interface.
https://bugzilla.redhat.com/show_bug.cgi?id=1110465
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
Always take a reference to the manager when scheaduling an asynchronous
operations. In fact, all callers want to keep the manager alive as long
as there are operations in progress.
Refactor NMFirewallManager to have consistent semantics about
asynchronous calls.
- the callback is always invoked exactly once, but never
synchronously when starting the operation.
- while cancelling the request, the callback is invoked
synchronously with respect to the cancel operation.
- you can cancel a request once (and once only).
- you cannot cancel the request once the callback is invoked.
- when disposing the object with requests pending, the
callbacks are invoked synchronously.
- Add a callback argument to nm_firewall_manager_remove_from_zone().
Otherwise, the user never knows whether a call is still pending and
cancellable (as complete operations cannot be cancelled).
In fact, it makes no sense trying to cancel a call if you don't care
about when it completes.
- get rid of PENDING_CALL_DUMMY. The dummy callback allows cancellation
any number of times. We want to catch wrong usage by asserting that an
operation is only cancelled once.
- nm_firewall_manager_cancel_call() doesn't need the manager argument.
Either the call-id is valid (and has a valid pointer to the manager),
or there is a bug and it is a dangling pointer.
Give it a proper NMFirewallManager* prefix to make it clear where the type belongs.
Also, we will add a similar callback for nm_firewall_manager_remove_from_zone(),
so reflect that in the name.
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
Got a crash with unknown reason on nm-1-0 branch. It's unclear why,
but the reason could be that a lease in client_receive_advertise()
was cleared, but not its timers.
Backtrace from nm-1-0 branch (note that the systemd code where the crash
happend is different, but similar):
#0 sd_event_source_unref (s=0xf5c007e8fb894853) at dhcp-manager/systemd-dhcp/nm-sd-adapt.c:53
#1 0x0000555555682340 in client_timeout_t1 (s=<optimized out>, usec=<optimized out>, userdata=0x5555559f5240)
at dhcp-manager/systemd-dhcp/src/libsystemd-network/sd-dhcp6-client.c:451
#2 0x00005555556a078f in time_ready (source=0x5555559f3c20) at dhcp-manager/systemd-dhcp/nm-sd-adapt.c:146
#3 0x00007ffff4a481b3 in g_timeout_dispatch () from /lib64/libglib-2.0.so.0
#4 0x00007ffff4a4779a in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#5 0x00007ffff4a47ae8 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0
#6 0x00007ffff4a47dba in g_main_loop_run () from /lib64/libglib-2.0.so.0
#7 0x0000555555597073 in main (argc=1, argv=0x7fffffffe2b8) at main.c:512
Equivalent upstream systemd patch:
https://github.com/systemd/systemd/pull/1332f89087272bhttps://bugzilla.redhat.com/show_bug.cgi?id=1260727
sd_event_source is either used for sd_event_add_io() or sd_event_add_time().
Depending on the use, different fields of the struct are relevant. Refactor
the struct to have a union.
This reduces the size of the struct, but more importantly, it makes it
clear which fields are used in which context.
Systemd supports omitting the output source argument. In this case,
the created event source is floating and the reference count
is handled properly.
We have however no callers that make use of that functionality, so
instead of implementing floating references, assert that we don't
need it.
This isn't a change in behavior, because previously the could would just
SEGFAULT if a caller didn't want to take ownership of the created event.
Especially systemd, which makes use of the error argument for logging, likes
to represent errors as negative numbers. We hence must invert a negative error
code to get the real errno.
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
- Reorder statements, to first g_return_if_fail() and log state-change.
- Also log a message when leaving _set_state_full() early due to missing firmware.
g_dbus_message_get_interface() can return NULL in the message filter,
for example when the client does:
#!/usr/bin/env python
import dbus
bus = dbus.SystemBus()
proxy = bus.get_object("org.freedesktop.NetworkManager",
"/org/freedesktop/NetworkManager")
proxy.foobar()
Use g_strcmp0() to compare the interface and member names.
Fixes: 34ba4e14b8
While an NMExportedObject is exported (i.e. registered at NMBusManager),
it has a list of GDBusInterfaceSkeleton interfaces. The properties of
the nm-object are bound to the interfaces and the signals connected.
Previously, when unexporting the NMExportedObject, we would only unref
the interfaces, but not explicitly disconnect. As there is no guarantee
that the lifetime of the interfaces is shorter then the lifetime of the
nm-object, hence, explicitly disconnect.
Clone the connection upon activation. This makes it safe for the user
to modify the original connection while it is activated.
This involves several changes:
- NMActiveConnection gets @settings_connection and @applied_connection.
To support add-and-activate, we constructing a NMActiveConnection with
no connection set. Previously, we would set the "connection" field to
a temporary NMConnection. Now NMManager piggybacks this temporary
connection as object-data (TAG_ACTIVE_CONNETION_ADD_AND_ACTIVATE).
- get rid of the functions nm_active_connection_get_connection_type()
and nm_active_connection_get_connection_uuid(). From their names
it is unclear whether this returns the settings or applied connection.
The (few) callers should figure that out themselves.
- rename nm_active_connection_get_id() to
nm_active_connection_get_settings_connection_id(). This function
is only used internally for logging.
- dispatcher calls now get two connections as well. The
applied-connection is used for the connection data, while
the settings-connection is used for the connection path.
- needs special handling for properties that apply immediately
when changed (nm_device_reapply_settings_immediately()).
Co-Authored-By: Thomas Haller <thaller@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=724041
NMSecretAgent (and in turn NMAgentManager) used the @connection argument both
for the connection data, but also for the connection path. Detangle these, and
accept the path separate from the connection.
This makes NMSecretAgent and NMAgentManager truly operate on a plain
NMConnection, without the non-obvious requirement, that the path of the
connection must be set.
