Link related functions should have a "nm_platform_link" prefix. Rename.
Naming is a subjective matter and one might argue that omitting
the "link" part from the name is shorter and even preferred.
However, I think functions related to links should have a common
prefix as the underlyings are strongly related.
dhclient adds a trailing dot to domain search list entries received
from the server, while the same domains received by other means
(dhcpcd on RA) don't have the final dot. The result is that
resolv.conf can be populated with duplicated entries.
Fix this by stripping the trailing dot when a new search domain is
added to a IP configuration.
https://bugzilla.gnome.org/show_bug.cgi?id=758777
The new object type represents tunnels over IPv4 and IPv6.
We have a single setting type (NMSettingIPTunnel) for tunnels and it
can't be shared among different device factories. So we define also a
single device type for all tunnels.
This new object will also represent GRE tunnels, which before were
instantiated as NMDeviceGre and had a ".Device.Gre" D-Bus
interface. This commit introduces a change in behavior.
When a connection should be assumed and the generated connection did not
contain a wired setting, the connection did not match due to S390 properties.
Such a connection should be allowed to match to a connection with a wired
setting with default (empty) S390 properties.
This can happen when there is a VLAN profile configured that contains a wired
setting in it and NetworkManager is (re)started.
Example/reproducer:
$ nmcli con add type vlan con-name vlan-test autoconnect no dev em1 id 44
$ nmcli con mod vlan-test eth.mtu 1450 (modify the connection, so that it has a wired setting)
$ nmcli con up vlan-test (activate the connection)
$ sudo systemctl restart NetworkManager
$ nmcli device
check that 'vlan-test' connection is active on em1.44 device
(and not the auto-generated em1.44)
https://bugzilla.redhat.com/show_bug.cgi?id=1276343
RFC7217 introduces an alternative mechanism for creating addresses during
stateless IPv6 address configuration. It's supposed to create addresses whose
host part stays stable in a particular network but changes when the hosts
enters another network to mitigate possibility of tracking the host movement.
It can be used alongside RFC 4941 privacy extensions (temporary addresses)
and replaces the use of RFC 4862 interface identifiers.
The address creation mode is controlld by ip6.addr_gen_mode property
(ADDR_GEN_MODE in ifcfg-rh), with values of "stable-privacy" and "eui-64",
defaulting to "eui-64" if unspecified.
The host part of an address is computed by hashing a system-specific secret
salted with various stable values that identify the connection with a secure
hash algorithm:
RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)
For NetworkManager we use these parameters:
* F()
SHA256 hash function.
* Prefix
This is a network part of the /64 address
* Net_Iface
We use the interface name (e.g. "eth0"). This ensures the address won't
change with the change of interface hardware.
* Network_ID
We use the connection UUID here. This ensures the salt is different for
wireless networks with a different SSID as suggested by RFC7217.
* DAD_Counter
A per-address counter that increases with each DAD failure.
* secret_key
We store the secret key in /var/lib/NetworkManager/secret_key. If it's
shorter than 128 bits then it's rejected. If the file is not present we
initialize it by fetching 256 pseudo-random bits from /dev/urandom on
first use.
Duplicate address detection uses IDGEN_RETRIES = 3 and does not utilize the
IDGEN_DELAY delay (despite it SHOULD). This is for ease of implementation
and may change in future. Neither parameter is currently configurable.
Having a static string buffer for convenience is useful not only
for platform. Define the string buffer in NetworkManagerUtils.h,
so that all to-string functions can reuse *one* buffer.
Of course, this has the potential danger, that different
to-string method might reuse the same buffer. Hence, low-level
library functions are adviced to use their own buffer, because
an upper level might already use the global buffer for another
string.
The peer-address (IFA_ADDRESS) can also be all-zero (0.0.0.0).
That is distinct from an usual address without explicit peer-address,
which implicitly has the same peer and local address.
Previously, we treated an all-zero peer_address as having peer and
local address equal. This is especially grave, because the peer is part
of the primary key for an IPv4 address. So we not only get a property of
the address wrong, but we wrongly consider two different addresses as
one and the same.
To properly handle these addresses, we always must explicitly set the peer.
Arguably, it is more convenient to use the static buffer as
it saves typing.
But having such a low-level function use a static buffer also
limits the way how to use it. As it was, you could not avoid
using the static buffer.
E.g. you cannot do:
char buf[100];
_LOGD ("nmp-object: %s; platform-link: %s",
nmp_object_to_string (nmpobj, buf, sizeof(buf)),
nm_platform_link_to_string (link));
This will fail for non-obvious reasons because both
to-string functions end up using the same static buffer.
Also change the to-string implementations to accept NULL
as valid and return it as "(null)".
https://bugzilla.gnome.org/show_bug.cgi?id=756427
The peer-address seems less important then the prefix-length.
Also, nm_platform_ip4_address_delete() has the peer-address
argument as last.
Soon ip4_address_get() also receives a peer-address argument,
so get the order right first.
No longer support disabling the global-dns configuration via the
"enable" option.
Instead, the user can put the entire dns-configuration in one separate
snippet, and disable it altogether with ".config.enable".
Support a new configuration option
[.config]
enable=<ENABLED>
for configuration snippets.
This new [.config] section is only relevant within the snippet itself
and it is not merged into the combined configuration.
Currently only the "enable" key is supported. If the "enable" key is
missing, it obviously defaults to being enabled. It allows snippets
to be skipped from loading. The main configuration "NetworkManager.conf"
cannot be skipped.
<ENABLED> can be a boolean value (false), to skip a configuration
snippet from loading.
It can also be a string to match against the NetworkManager version,
like "enable=nm-version-min:1.1,nm-version-min:1.0.6"
There are several motivations for this:
- the user can disable an entire configuration snippet by toggeling
one entry.
This generalizes the functionality of the global-dns.enable
setting, but in a way that applies to configuration on a per-file
basis.
- for developing, we often switch between different versions of
NetworkManager. Thus, we might want to use different configuration.
E.g. before global-dns options, I want to use "dns=none" and manage
resolv.conf myself. Now, I can use global-dns setting to do that.
That can be achieved with something like the following (not exactly,
it's an example only):
[.config]
enable=nm-version-min:1.1
[main]
dns=default
[global-dns-domain-*]
nameserver=127.0.0.1
Arguably, this would be more awesome, if we would bump our micro devel
version (1.1.0) more often while developing 1.2.0 (*hint*).
- in principle, packages could drop configuration snippets and enable
them based on the NetworkManager version.
- with the "env:" spec, you can enable/disable snippets by configuring
an environment variable. Again, useful for testing and developing.
For libnm library, "nm-dbus-interface.h" contains defines like the D-Bus
paths of NetworkManager. It is desirable to have this header usable without
having a dependency on "glib.h", for example for a QT application. For that,
commit c0852964a8 removed that dependancy.
For libnm-glib library, the analog to "nm-dbus-interface.h" is
"NetworkManager.h", and the same applies there. Commit
159e827a72 removed that include.
However, that broke build on PackageKit [1] which expected to get the
version macros by including "NetworkManager.h". So at least for libnm-glib,
we need to preserve old behavior so that a user including
"NetworkManager.h" gets the version macros, but not "glib.h".
Extract the version macros to a new header file "nm-version-macros.h".
This header doesn't include "glib.h" and can be included from
"NetworkManager.h". This gives as previous behavior and a glib-free
include.
For libnm we still don't include "nm-version-macros.h" to "nm-dbus-interface.h".
Very few users will actually need the version macros, but not using
libnm.
Users that use libnm, should just include (libnm's) "NetworkManager.h" to
get all headers.
As a special case, a user who doesn't want to use glib/libnm, but still
needs both "nm-dbus-interface.h" and "nm-version-macros.h", can include
them both separately.
[1] https://github.com/hughsie/PackageKit/issues/85
Fixes: 4545a7fe96
There seems to be a bug in glib/ffi that hits on s390x/ppc64 architecture.
It causes @changes in nm-dns-manager.c:config_changed_cb() to be NONE,
although it is clearly set (see the related bug rh #1260577 for glib).
Workaround this, by making the argument type a plain guint.
Note that the ill behavior is caught by test_config_signal() in
"src/tests/config/test-config.c".
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1062301
On slow virtual machine, these tests could fail because the
timeout was too low. As in a successful run the timeouts should
not be reached anyway, just extend them.
The config-tests contain a NMTestDevice which derives from NMDevice.
However, for testing, it just skips the constructor and destructor of
NMDevice. This caused also the destructors of NMExportedObject to be skipped
and thus valgrind complained about leaked memory.
Fixes: 6fcc1deee0
Port remaining bits to gdbus and remove stray dbus-glib references
Drop the dbus-glib version check from configure, since nothing depends
on new dbus-glib any more.
Move nm-dbus-glib-types.h and nm-gvaluearray-compat.h from include/ to
libnm-util/ since they are now only used by libnm-util and libnm-glib.
The new flags are not yet used, so there is no change in functionality.
The flags NM_IP_CONFIG_MERGE_NO_ROUTES and NM_IP_CONFIG_MERGE_NO_DNS go
together with the 'ignore-auto-routes' and 'ignore-auto-dns' setting.
Note that for IPv4, NM_IP_CONFIG_MERGE_NO_DNS also ignores NIS, WINS, and dns-options.
This is different from current other places that handle 'ignore-auto-dns'
and only care about nameservers, domains, and searches.
This internal header file should be included by our internal source
code files and header files. It includes in one place other headers
that constitute to a minimal set of required headers. Most notably
this is <glib.h> and our "nm-glib.h" header.
Note that public header files and example source code cannot include
this file as "nm-default.h" is internal only.
Our gdbus generated types use the same names as their corresponding
"real" types, but with "NM" changed to "NMDBus".
Unfortunately, that means that introspection/nmdbus-manager.c (the
generated type for src/nm-manager.c) uses the same type name as the
entirely unrelated src/nm-dbus-manager.c.
Fix this by removing the "d" from src/nm-dbus-manager.c. (We could
rename the generated type instead, but then it becomes inconsistent
with all the other generated types, and we're already using it as
"NMDBusManager" in libnm/nm-manager.c.)
Rather than randomly including one or more of <glib.h>,
<glib-object.h>, and <gio/gio.h> everywhere (and forgetting to include
"nm-glib-compat.h" most of the time), rename nm-glib-compat.h to
nm-glib.h, include <gio/gio.h> from there, and then change all .c
files in NM to include "nm-glib.h" rather than including the glib
headers directly.
(Public headers files still have to include the real glib headers,
since nm-glib.h isn't installed...)
Also, remove glib includes from header files that are already
including a base object header file (which must itself already include
the glib headers).
Add an argument @full_sync to the sync method of NMRouteManager.
@full_sync was what we did up to now, meaning, we removed every
route on the interface that was no on our internal list of known
routes.
Now with !@full_sync, only remove routes that were tracked previously.
This means, we will only remove routes that were added by us previously.
Don't make use of the new option yet. So there is no change of behavior
yet.
Kernel does not allow to add the same route (as determined by network/plen,metric)
on two different interfaces (ifindex). In case of conflict, NMRouteManager used to
ignore any but the firstly added route.
On the other hand, we cannot add a gateway-route, if there is no direct
route to the gateway. Hence, skipping duplicate routes can mean that we
skip a direct route what was necessary to add another gateway-route,
which then leads to a failure to add that route.
This also applies to IPv4 device routes that since recently are managed
by NMRouteManager.
For example, say you connect two interfaces to the same IP subnet.
The route-metric can conflict if the interfaces are of the same type
or if the user explicitly configured a conflict.
In case of conflicts, NMRouteManager would only configure the first
appearing route and skip the shadowed route on the second interface.
Now we cannot configure gateway-routes on the second interface because
the gateway is unreachable.
There are many scenarios where this issue can happen, especially with
default-routes and user-configured-routes.
For example with default-routes, ip4_config_merge_and_apply() would check
if the default-gateway requires an explict route and possibly add it.
But then NMRouteManager might not add the route because it is shadowed
by a route on an other interface.
This patch solves the issue by having NMRouteManager configure shadowed
routes too, similar to what NMDefaultRouteManager does.
It does that by searching for an unused, non-conflicting, higher metric
for the route, i.e. bump the metric by 1 until we can add it without
conflict.
Also note that NMRouteManager still ensures that for conflicting routes
the best route sticks to the interface that configured it first. That
means if you later add the conflicting route on another interface, it
will be added with higher metric and the data is still routed along the
first interface.
We already support setting configuration values, either:
(1) set any internal section, i.e. groups starting with [.intern*].
Those values don't ever interfere with that the user can
configure.
(2) set individual properties that overwrite user configuration.
When doing that, we record the value from user configuration
and on load, we reject our internal overwrite if the user
configuration changed in the meantime.
This is done by storing the values with ".set." and ".was." prefixes.
Now add support for "atomic sections". In this case, certain groups
can be marked as "atomic". When writing to such sections, we overwrite
the entire user-provided setting.
We also record the values from user configuration, and reject our
internal value if we notice modifications. This basically extends
(2) from individual properties to the entire section.
Internal configuration is written as keyfile to
NMSTATEDIR"/NetworkManager-intern.conf"
Basically, the content of this file is merged with user
configuration from "NetworkManager.conf" files. After loading
the configuration, NMConfig exposes a merged view of user-provided
settings and internal overwrites.
All sections/groups named [.intern*] are reserved for internal
configuration values. They can be written by API, but are ignored
when the user sets them via "NetworkManager.conf". For these
internal sections, no conflicts can arise.
We can also overwrite individual properties from user configuration.
In this case, we store the value we want to set, but also remember
the value that the user configuration had, at the time of setting.
If on a later reload the user configuration changed, we ignore our
internal value -- as we assume that the user modified the value
afterwards.
We can also hide/delete value from user configuration.
This works on a per-setting basis.
This allows packages to install their configuration snippets to
"/usr/", which is a better place for system-provided configuration
files then "/etc".
"/usr/lib/NetworkManager/conf.d/" is read first, so that the values
in /etc have higher priority.
In general, we want to move system-provided configuration away from
/etc, so that a user can do a "factory-reset" by purging /etc.
https://bugzilla.gnome.org/show_bug.cgi?id=738853
It is wrong to blindly merge keys that have an 'option+' or 'option-'.
Merging options is only possibly when we understand what the option
means and how to merge it.
No longer handle every setting but only those that are explicitly known
to be string-lists (or device-specs).
We have a special implemenation nm_match_spec_split() to split
a string. We also need the reverse operation to be able to convert
a list of specs to string without loss.
In some cases we want the returned value to be stripped. In some cases,
we want to read the raw value instead of the string parsed by GKeyFile.
Add an flags argument to nm_config_data_get_value(). It is up to the caller
to determine the exact meaning (and whether to strip).
By adding the flags argument, the caller can get the desired behavior easier
without having to workaround it afterwards. But more importantly, it becomes
apparent that there are different ways to retrieve the value and the caller
should decide on the details.
We have a hack to extend GKeyFile to support specifying an 'option+'
key. Also add support for 'option-'.
Options that make use of these modifiers can only be string lists.
So do the concatenation not based on plain strings, but by treating
the values as string lists. Also, don't add duplicates.
We support the "NetworkManager.conf" sections '[connection]' and
'[connection.\+]' (with arbitrary suffix).
Fix the order of how we evaluate these section.
Note that the literal '[connection]' section is always evaluated lastly
after any other '[connection.\+]' section.
Within one file, we want to evaluate the sections in top-to-bottom
order. But accross multiple files, we want to order them
later-files-first. That gives a reasonable behavior if the user
looks at one file, and also if he wants to overwrite configuration
via configuration snippets like "conf.d/99-last.conf".
Note that if a later file extends/overwrites a section defined in an
earlier file, the section is still considered with lower priority
This is intentional, because the user ~extends~ a lower priority
section. If he wants to add a higher priority section, he should
choose a new suffix.
Fixes: dc0193ac02
