Add new capabilities CAP_FREQ_2GHZ and CAP_FREQ_5GHZ to indicate the
frequency bands supported by a Wifi device.
Add also CAP_FREQ_VALID, which is set when the values of the other 2
capabilities are available.
Original patch by Dan Williams <dcbw@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=723295
In theory, NM_VPN_PLUGIN_ERROR should have names under
org.freedesktop.NetworkManager.VPN.Plugin, but for historical reasons,
it's actually org.freedesktop.NetworkManager.VPN.Error.
A few places in the NMSupplicantInterface API and in NMDeviceWifi's
use of it were still using "GHashTable *properties" where they should
have been using "GVariant *properties". (This didn't cause any actual
problems because nothing was looking at those arguments.)
(Also fix a comment typo.)
Let the server decide which device to use if the user didn't explicitly
specify the interface, wireless access point or a wimax nsp.
The server will just reuse the device for an already active connection
or potentially do a better guess.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
The connection now might be being activated on another device. Defer the
removal until we're sure the activation request will proceed and only add the
active connection afterwards.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
If a connection is already active let's keep it on the same device. This makes
it possible to reactivate a connection without client knowing which device is
it active on.
https://bugzilla.gnome.org/show_bug.cgi?id=730492
The merge of lr/udev-unmanaged-fd731014 made all devices wait until
udev found them, but that makes these three device types fail activate
when created by NM itself.
Since their availability depended on IFF_UP, they could not be
activated (eg, 'nmcli con up team0') until they were IFF_UP. But
when they are created by NM, although NM knows the ifindex the
platform ignores the interface until udev finds it. Thus immediately
after creating the interface in _internal_activate_device() it
won't be known to the platform, so the nm_device_is_available()
check that controls whether the device moves to DISCONNECTED
will fail. This prevents any activation and emits the message:
"Connection 'foo' is not available on the device %s at this time."
because the device is still in the UNAVAILABLE state.
danw asked why we care about IFF_UP for these devices, and I can't
remember why, and I don't think it makes sense to require now.
https://bugzilla.gnome.org/show_bug.cgi?id=746918
teamd can recover interface state on its own, so if it died unexpectedly
we don't need to fail the device. Also, if for some reason a teamd is
already up and running when activating the interface, we can ask for
its configuration and if it has the same configuration we are about to
use, just talk to the existing copy instead of killing it.
Since f85513b (device: do not touch sysctls after the device was removed) the
device is not unconfigured/cleaned up when it's removed. When we're quitting
the device is not actually removed, we're just unmanaging it -- let's just
use a different reason so that the cleanup runs.
Fixes: f85513b8e4
Fixes the following warnings in nm-dns-manager.c with NETCONFIG_PATH set:
dns-manager/nm-dns-manager.c: In function 'dispatch_netconfig':
dns-manager/nm-dns-manager.c:313:2: warning: implicit declaration of function 'waitpid' [-Wimplicit-function-declaration]
ret = waitpid (pid, NULL, 0);
^
dns-manager/nm-dns-manager.c:271:14: warning: unused variable 'tmp' [-Wunused-variable]
char *str, *tmp;
^
dns-manager/nm-dns-manager.c:329:13: warning: 'ret' may be used uninitialized in this function [-Wmaybe-uninitialized]
return ret > 0;
^
Fixes the following error in nm-dns-manager.c with NETCONFIG_PATH set:
dns-manager/nm-dns-manager.c:320:4: error: too many arguments to function 'g_set_error_literal'
g_set_error_literal (error,
NM already understands the command line argument --g-fatal-warnings
which causes setting of g_log_set_always_fatal().
Also interpret the "fatal-warnings" token in NM_DEBUG environment
variable and in main.debug configuration setting.
Usage hint: either set
$ export NM_DEBUG=RLIMIT_CORE,fatal-warnings
or add the following section to NetworkManager.conf
[main]
debug=RLIMIT_CORE,fatal-warnings
https://mail.gnome.org/archives/networkmanager-list/2015-March/msg00093.html
If the child dies, or something kills the child externally, refresh
DNS which should respawn the child, similar to what we do with
wpa_supplicant, teamd, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=728342
