The 'new-connection' signal of a GDBusServer is emitted by default
through an idle source and the actual message processing starts only
after a signal handler returns TRUE.
Thus, before the signal handler has the chance to run, the GDBus
worker thread may detect that the connection is closed and schedule
the delivery of the 'closed' signal through another idle source.
After the termination of the 'new-connection' handler, the 'closed'
handler is executed, which cancels the subscription to GDBus signals
before any message has been processed.
This looks like a bug in GDBusServer; to work around it, just delay
the close of connection to let the signal dispatch run first.
https://bugzilla.gnome.org/show_bug.cgi?id=755170
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
Otherwise I get the following error (iwhile building in Jenkins):
In file included from ../include/nm-default.h:45:0,
from nm-config.c:27:
nm-config.c: In function 'nm_config_set_global_dns':
../include/gsystem-local-alloc.h:31:10: error: 'group_name' may be used uninitialized in this function [-Werror=maybe-uninitialized]
func (*(Type*)v); \
^
nm-config.c:1483:17: note: 'group_name' was declared here
gs_free char *group_name;
^
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
We now (since 3272ff6 libnm/libnm-glib: don't quit in the middle of asking for
secrets) always hook on the quit timer when NM asks the plugin if it needs
secrets. The timer is 20 seconds, which seems too short.
Let's make it three minutes. Don't bother adding another timer or using a
distinct timeout: it does no harm for the plugin to remain unused for three
minutes on a bus.
Another option would be to completely unhook it; however the plugin wouldn't
learn if the user cancelled the NM's secrets request and would remain unused
on the bus forever.
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
NetworkManager only allows one 'client:user-id' to register as secret
agent. Thus, when starting nmtui in two terminals, creating the secret
agent can fail.
This can lead to a crash.
https://bugzilla.gnome.org/show_bug.cgi?id=755883
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
Otherwise the check is effectively a no-op and unknown options still get
turned on. This results in unknown warnings when build without
--with-extra-warnings=error:
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
- export device's S390 subchannels on D-Bus
- update 390 subchannels comparison for connection vs.device compatibility
- support s390 subchannels in libnm and nmcli
https://bugzilla.gnome.org/show_bug.cgi?id=755610
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
This is a forward port of commit 6f616d4c4b04d5478f60d0311317bc84c5459ea4
which added this patch on nm-1-0 branch.
However, the reason stated there is wrong because we don't need this
to fix Qt examples. Building Qt examples was fixed in that "nm-dbus-interface.h"
no longer drags in "nm-version.h".
On the other hand, we still want "nm-version.h" to be self-contained,
and include "glib.h" as it needs it.
We want "nm-dbus-interface.h" to have no dependancy on libnm and glib.
That way, it is usable for example in the QT examples without dragging
in dependencies to glib.
Also drop all the unneccessary include to "nm-dbus-interface.h", which
we already get by directly or indirectly including "nm-core-types.h".
