It's useful to track the flags for IPv4 addresses too.
- we might want to sort IPv4 addresses according to whether they
are permanent or dynamic.
- later we want to set IFA_F_NOPREFIXROUTE also for IPv4 addresses.
While the ability to "set" a flag doesn't necessarily require that we
also keep the flags present in NMPlatformIP4Address, it is more consistent.
This test makes sense because "test-systemd" is not
linked against any other systemd library. So this test
verifies that our libsystemd clone is self contained.
Most interestingly is also, whether we can link libsystemd.a without
having undefined references (which might be wrongly satisfied by an
externally loaded libsystem shared library.
"NetworkManagerUtils.h" contains a bunch of helper tools for core
daemon ("src/").
Unfortunately, it has dependencies to other parts of core,
such as "nm-device.h" and "nm-platform.h". Split out a part
of tools that are independent so that they can be used without
dragging in other dependencies.
"nm-core-utils.h" should only use libnm-core, "nm-logging.h"
and shared.
"NetworkManagerUtils.h" should provide all "nm-core-utils.h" and
possibly other utilities that have larger dependencies.
"nm-logging.h" is a basic core module that should have few other
dependencies. Instead of letting nm-logging.c directly call a function
from "nm-linux-platform.c", let platform register a handler as needed.
This way, you can build a core library containing nm-logging but no
nm-platform.
On older NM versions the default value for vlan.flags was 0, but then
the actual value set on interfaces was REORDER_HDR. In order to
maintain backwards compatibility in behavior, remove the special
handling of vlan.flags so that a missing key is treated as the default
value REORDER_HDR.
https://bugzilla.gnome.org/show_bug.cgi?id=762626
On NM 1.0 connections were created by default without the REORDER_HDR
flag, but then due to a bug in platform code (fixed in [1]), the
kernel interface always had the flag set.
Now that the setting is honored, users upgrading to the new version of
NM will see a change from the previous behavior, since interfaces will
not have REORDER_HDR and this will certainly break functionality.
The only solution here seems to be to ignore the REORDER_HDR variable
in ifcfg files (since it never had any effect) and introduce a new
NO_REORDER_HDR option for the VLAN_FLAGS variable which allows to turn
the flag off. The consequence is that the flag will be set for all old
connections.
This change introduces an incompatibility with initscripts, however is
necessary to avoid breaking user functionality upon upgrade.
Connections created through NetworkManager will still be parsed
correctly by initscripts (since we always write the REORDER_HDR
variable).
[1] db62fc9d72 ("platform: fix adding VLAN flags")
https://bugzilla.gnome.org/show_bug.cgi?id=762626
There are far too many "flags". Rename the "flags" to "n_ifa_flags"
which reminds to "ifa_flags" in 'struct ifaddrmsg', but with a
distinctive "n_" prefix.
There are far too many "flags". Rename the "flags" to "n_ifi_flags"
which reminds to "ifi_flags" in 'struct ifinfomsg', but with a
distinctive "n_" prefix.
g_str_hash() can not be called with NULL. Ensure that we don't crash.
Thereby, refactor the hashing algorithm because the chassis-id and
port-id are small numbers and xor-ing can cancel them easily.
The header files are not compiled directly, but always included while compiling
other source files. We already require every source file to include "nm-sd-adapt.h"
as first, thus we don't need the include in the headers too.
Don't rely on what's already on the device. It could be that the MAC address
set on the device is not meaningful -- the NM crashed while two devices were
teamed together and now they have the same hardware address and now it's
impossible to bond them with mode=5.
This saves 110 bytes (which is 1/29986680757 of the size of the books in the
Library of Congress).
Also, the function is static; not using the nm_device_ prefix is preferred.
The value written to sysctl is usually a short string. It makes sense
to optimize for this case and avoid allocating a temporary string
on the heap.
An alternative would be to use writev(), which effectively does the same
and also creates a temporary buffer (preferably stack allocated).
https://mail.gnome.org/archives/networkmanager-list/2016-February/msg00070.html
This fixes the issue where all Ad-Hoc networks try to connect one after one on
NM startup instead of the managed network that has AP available.
Fixes: e2637760f1
Since commit 87a3df2e57, the unmanaged
flag NM_UNMANAGED_USER_SETTINGS could be overwritten via an explict
user decision (NM_UNMANAGED_USER_EXPLICIT).
It makes sense to allow user configuration from file to be changable
by an explict user action via D-Bus at runtime.
However, it also changes behavior for devices that are currently explicitly
managed. Previously, a reload of the NM_UNMANAGED_USER_SETTINGS would
immediately unmanaged the device:
- for keyfile: send SIGHUP to reload NetworkManager.conf
- for ifcfg-rh: `nmcli connection [re]load`
So this change in behavior could negatively affect users who rely
on being able to configure "NM_CONTROLLED=no" and expect to unmanaged
the device immediately. Thus revert the change.
Note that NM_UNMANAGED_USER_SETTINGS is anyway ugly and should be
deprecated:
- for keyfile, why having the option "keyfile.unmanaged-devices"
instead of a generic options?
- for ifcfg-rh, why put per-device configuration in a per-connection
file?
The preferred way is to configure NM_UNMANAGED_USER_UDEV via
"ENV{NM_UNMANAGED}". Maybe we should also add a new configuration
scheme via NetworkManager.conf.
https://bugzilla.gnome.org/show_bug.cgi?id=762331
The NM_UNMANAGED_USER_SETTINGS flags are determined by the settings plugins.
That is, either:
- keyfile's "unmanaged-devices" configuration option
- ifcfg-rh's "NM_CONTROLLED" option
- ifnet's "managed" option
Rename NM_UNMANAGED_USER_CONFIG to NM_UNMANAGED_USER_SETTINGS to reflect
that it this is user configuration determined by the settings plugin.
Change the logging format. For syslog, we will now always
print the timestamp (also for <info> and <warn> messages).
Also, when printing the file location, we will always
align it.
For journal logging, also enable the timestamp. While the timestamp
is already captured separately by journal, most of the time a user
will look at the syslog like output from journal, so we want the
timestamps there too.
- All internal source files (except "examples", which are not internal)
should include "config.h" first. As also all internal source
files should include "nm-default.h", let "config.h" be included
by "nm-default.h" and include "nm-default.h" as first in every
source file.
We already wanted to include "nm-default.h" before other headers
because it might contains some fixes (like "nm-glib.h" compatibility)
that is required first.
- After including "nm-default.h", we optinally allow for including the
corresponding header file for the source file at hand. The idea
is to ensure that each header file is self contained.
- Don't include "config.h" or "nm-default.h" in any header file
(except "nm-sd-adapt.h"). Public headers anyway must not include
these headers, and internal headers are never included after
"nm-default.h", as of the first previous point.
- Include all internal headers with quotes instead of angle brackets.
In practice it doesn't matter, because in our public headers we must
include other headers with angle brackets. As we use our public
headers also to compile our interal source files, effectively the
result must be the same. Still do it for consistency.
- Except for <config.h> itself. Include it with angle brackets as suggested by
https://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers
