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.
And rename the function to nm_main_utils_ensure_not_running_pidfile()
to match the other _ensure_ functions that exit(1).
Also no longer pass @name to nm_main_utils_ensure_not_running_pidfile()
and use g_get_prgname() instead.
nm_main_utils_ensure_not_running_pidfile() checks that the running
process has the same program name, so this changes behavior if the
user renamed the binary. Before, we would check whether the running
process is named 'NetworkManager' ('nm-iface-helper'). Now we check
whether the process has the same name as the current process.
This means, that if you rename the binary to 'NetworkManager2' we
would now only detect a conflicting 'NetworkManager2'. Before we would
only detect conflicting 'NetworkManager' binaries.
Move call to nm_main_utils_early_setup() to a separate function.
Also move the @options array away from the main function, saving
a few bytes on the stack.
Now only do_early_setup() modifies the @global_opt structure.
Move the variables to a static struct so that we can factor
out some of the initialization code.
Also it's nice to have all options placed together in one struct so
that is is obvious which static variables are part of the command line
options, and which have other use.
Configuration commit is an unsafe thing to do for assumed connections,
it can remove an externally added address we don't know about yet.
The device already has a link-local address; for an assumed connection
it's the reason we assumed the method=link-local in the first place.
Paths to sysctls don't use ifindex and device names can be reused. If someone
removes a device and quickly creates a device with the same name, chances are
we're cleaning up the device that was just added.
Sadly, it seems there's no better API than sysctl-- neither netlink nor procfs
symlinks with ifindex or anything like that.
There won't be any further requests, so there's no point in keeping
the connection alive. Even if the HTTP server doesn't care, proxy
servers in-between might keep the connection open for a couple seconds
for keepalive, and we might as well be nice to them and tell them we
don't need to keep it alive.
It would subtract the configuration from device confguration that's not yet
applied. This a the race where the loose the address while activating a
connection that has both IPv6 and IPv4 configuration.
Fixes: 557667df12https://bugzilla.gnome.org/show_bug.cgi?id=746066
These functions will sometimes get called on updates to the device's IP
config due to external changes, or when addresses get flushed from the
device when activating it. If the device is a slave device, then at
this point its NMConnection won't have an IP settings. Suppress the
warning that gets printed when s_ip == NULL, because it's expected.
keyfile should become our main import/export format. It is desirable,
that a keyfile can contain every aspect of a connection.
For blob certificates, the writer in core daemon would always write
them to a file and convert the scheme to path.
This behavior is not great for a (hyptetical) `nmcli connection export`
command because it would have to export them somehow outside of keyfile,
e.g. by writing them to temporary files.
Instead, if the write handler does not handle a certificate, use a
default implementation in nm_keyfile_write() which adds the blob inside
the keyfile.
Interestingly, keyfile reader already supported reading certificate
blobs. But this legacy format accepts the blob as arbitrary
binary without marking the format and without scheme prefix.
Instead of writing the binary data directly, write it with a new
uri scheme "data:;base64," and encode it in base64.
Also go through some lengths to make sure that whatever path
keyfile plugin writes, can be read back again. That is, because
keyfile writer preferably writes relative paths without prefix.
Add nm_keyfile_detect_unqualified_path_scheme() to encapsulate
the detection of pathnames without file:// prefix and use it to
check whether the path name must be fully qualified.
