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.)
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
NM was killing the dnsmasq local caching nameserver process and immediately
starting a new one, and new process couldn't bind to 127.0.0.1 because the
old one hadn't quit yet. Thus the new process quit, and the user was
left with no split DNS at all.
While this does introduce more synchronous waiting into the connection
process, it's not that much time and NM will kill dnsmasq if it hasn't
quit after 1 second. The longer-term fix is to use dnsmasq's D-Bus
interface to update DNS without respawning it.
https://bugzilla.gnome.org/show_bug.cgi?id=728342https://bugzilla.redhat.com/show_bug.cgi?id=1161232
Some device types (s390 OSA and ipvlan) can use the same link-layer address
for multiple virtual interfaces, and the kernel used the dev_id property
to differentiate these devices when constructing the IID. NM should do
this too to prevent IID clashes.
https://bugzilla.redhat.com/show_bug.cgi?id=1101809
udev doesn't know about the device yet when NM creates it internally.
NetworkManager[9275]: <info> (team0): carrier is OFF
NetworkManager[9275]: <info> (team0): new Team device (driver: 'team' ifindex: 16)
(NetworkManager:9275): GUdev-CRITICAL **: g_udev_device_get_property: assertion 'G_UDEV_IS_DEVICE (device)' failed
NetworkManager[9275]: <info> (team0): exported as /org/freedesktop/NetworkManager/Devices/5
Some out of tree drivers add Ethernet devices that are supposed to be managed
by other their tooling, e.g. VirtualBox or VMWare.
Rather than hardcoding their drivers (at least VirtualBox doesn't even set a
"driver" property in sysfs) or hardcoding a logic that identifies such devices
let's just add a possibility to blacklist them in udev. This makes it possible
for whoever who ships such a driver to ship rules that prevent NetworkManager
from managing the device itself.
Furthermore it makes it possible for the user with special needs leverage the
flexibility of udev rules to override the defaults. In the end the user can
decide to let NetworkManager manage default-unmanaged interfaces such as VEth
or turn on default-unmanaged for devices on a particular bus.
An udev rule for VirtualBox would look like this:
SUBSYSTEM=="net", ENV{INTERFACE}=="vboxnet[0-9]*", ENV{NM_UNMANAGED}="1"
There's no udev running in containers, it only starts if /sys is writable. If a
hardware device is added to the container's namespace NM would not announce it.
This also removes the software link special case -- the software links will now
wait for udev initialization (in case udev is there) as well. There's no reason
to treat them differently anymore. This makes it possible to use udev properties
of the software links.
https://bugzilla.gnome.org/show_bug.cgi?id=740526
libnm-core treated the UNKNOWN WEP key type as KEY. Relax that
and try to guess the correct type based on the key.
This is for example important if you have a valid connection with
wep-key-type=0 (unknown)
If you request passwords for such a connection, the user cannot
enter them in password format -- but there is no UI indication
that the password must be KEY.
systemd considers the startup time of NetworkManager until the D-Bus
service is claimed. By doing that earlier, this time is significantly
reduced.
This has the advantage, that services that are ordered to start
after NetworkManager can start earlier. Most notably, 'network.target'
orders itself After=NetworkManager.service and many services are ordered
After=network.target.
$ systemd-analyze blame | grep NetworkManager.service
Create the rundir earlier and before setting up nm-logging.
nm_main_utils_ensure_rundir() errors out with fprintf(stderr)
and does not need nm-logging.
