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
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 devices (s390 and ipvlan) use the same MAC address for
different interfaces, but dev_id differentiates them. So we
must use dev_id to avoid IID conflicts.
https://bugzilla.redhat.com/show_bug.cgi?id=1101809
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
No idea why was it there in the first place.
This also fixes a bug that the rules file was conditionally included in dist
depending on presence of udev dir at configure time.
There are some out-of-tree drivers that create devices masquerading as
ethernets which are supposed to use their own management tools. Avoid touching
them.
The rules should be run after 80-net-setup-link.rules, so that the
ID_NET_DRIVER is set.
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"
