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"
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
The sort order of nm_setting_enumerate_values() affects the
order in which keyfile writer serializes the properties.
Have a defined, stable sort order by sorting the properties
by name (with prefering id,uuid,type for NMSettingConnection).
nm_connection_for_each_setting_value() is used by keyfile writer to iterate
over the settings and write the keyfile entires. The order there is important
as g_key_file_to_data() prints the groups in the order they were created.
To have a stable order and to have the [connection] entry first, sort the
settings.
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.
We must never fail verification of a connection based on a password
because the password is re-requested during activation.
Otherwise, if the user enters an invalid password for a (previously)
valid connection, the connection becomes invalid. NetworkManager does
not expect or handle that requesting password can make a connection
invalid.
Invalid passwords should be treated as wrong passwords. Only a UI
(such as nm-connection-editor or nmcli) should validate passwords
against a certain scheme.
Note that there is need_secrets() which on the contrary must check for
valid passwords.
Error scenario:
Connect to a WEP Wi-Fi, via `nmcli device wifi connect SSID`. The
generated connection has wep-key-type=0 (UNKNOWN) and wep-key-flags=0.
When trying to connect, NM will ask for secrets and set the wep-key0
field. After that, verification can fail (e.g. if the password is longer
then 64 chars).
Some refactoring of the main() functions for NetworkManager and
nm-iface-helper. Most notably, start the D-Bus service earlier so
that NetworkManager starts faster.
https://bugzilla.gnome.org/show_bug.cgi?id=746254
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.
