When a reverse DNS entry must be added to dnsmasq, instead of
considering IP addresses as classful use the prefix to compute one or
more "in-addr.arpa" according to CIDR rules.
https://bugzilla.gnome.org/show_bug.cgi?id=767174
For the most part, this patch just renames some change-flags, but
doesn't change much about them. The new name should better express
what they are.
A config-change signal can be emitted for different reasons:
when we receive a signal (SIGHUP, SIGUSR1, SIGUSR2) or for internal
reasons like resetting of no-auto-default or setting internal
values.
Depending on the reason, we want to perform different actions.
For example:
- we reload the configuration from disk on SIGHUP, but not for
SIGUSR1.
- For SIGUSR1 and SIGHUP, we want to update-dns, but not for SIGUSR2.
Another part of the change-flags encodes which part of the configuration
actually changed. Often, these parts can only change when re-reading
from disk (e.g. a SIGUSR1 will not change any configuration inside
NMConfig).
Later, we will have more causes, and accordingly more fine-grained
effects of what should be done on reload.
Instead of accessing the singleton getter nm_settings_get(), obtain
the settings instance from the device instance itself via
nm_device_get_settings().
A large part of "nm-test-utils.h" is only relevant for tests inside "src/"
directory, as they are helpers related to NetworkManager core part.
Split this part out of "nm-test-utils.h" header.
For addresses (NMPlatformIPAddress) the @addr_source field is ignored
on a platform level. That is, all addresses inside the platform cache
have this value set to NM_IP_CONFIG_SOURCE_KERNEL. Maybe, for that reason,
the source should not be a part of the NMPlatformIPAddress structure, but
it is convenient for users to piggy back the source inside the platform
address structure.
For routes, the source is stored in NMPlatformIPRoute's @rt_source
field. When adding a route to kernel, we set the @rtm_protocol of the
route depending on the source. However, we want to map different source
values to the same protocol value.
On the other hand, when kernel sends us a route that gets put inside
the cache, we must preserve the protocol value and must not map
different protocol values to the same source.
The reason is, that a user can add two routes that only differ by
@rtm_protocol. In that sense, the @rtm_protocol fields is part of the
unique ID of a kernel route, and thus different values must map to
different sources.
Fix this, by extending the range of NMIPConfigSource to contain
a range of protocol fields.
The "source" field of NMPlatformIPRoute (now "rt_source") maps to the
protocol field of the route. The source of NMPlatformIPAddress (now
"addr_source") has no direct equivalent in the kernel.
As their use is different, they should have different names. Also,
the name "source" is used all over the place. Hence give the fields
a more distinct name.
Valgrind doesn't like it, so don't use g_file_copy().
==10410== Syscall param ioctl(generic) points to unaddressable byte(s)
==10410== at 0x82E1707: ioctl (syscall-template.S:84)
==10410== by 0x7712E71: btrfs_reflink_with_progress (gfile.c:3012)
==10410== by 0x7712E71: file_copy_fallback (gfile.c:3186)
==10410== by 0x7712E71: g_file_copy (gfile.c:3394)
==10410== by 0x1350CA: test_config_state_file (test-config.c:948)
==10410== by 0x7D0845A: test_case_run (gtestutils.c:2158)
==10410== by 0x7D0845A: g_test_run_suite_internal (gtestutils.c:2241)
==10410== by 0x7D08622: g_test_run_suite_internal (gtestutils.c:2253)
==10410== by 0x7D0882D: g_test_run_suite (gtestutils.c:2328)
==10410== by 0x7D08850: g_test_run (gtestutils.c:1596)
==10410== by 0x12EFA4: main (test-config.c:1032)
==10410== Address 0x9 is not stack'd, malloc'd or (recently) free'd
==10410==
Fixes: e3a30665d7
After all, this state is stored persistently to /var/lib/NetworkManager,
and not to volatile storage in /var/run. Hence the name is better.
It's also shorter, so rename it.
The commit is mostly trivial, including update of code comments
and logging messages.
Fixes: 1b43c880ba
For internal compilation we want to be able to use deprecated
API without warnings.
Define the version min/max macros to effectively disable deprecation
warnings.
However, don't do it via CFLAGS option in the makefiles, instead hack it
to "nm-default.h". After all, *every* source file that is for internal
compilation needs to include this header as first.
Now we have:
"nm-sd.h" is a header file of NetworkManager with utilities
related to systemd. It can be used anywhere freely.
Also, systemd headers that are considered public API (like
"sd-event.h") can be used without restrictions.
When compiling the systemd sources, we always must include
"nm-sd-adapt.h" as first. Similarly, systemd headers must
not include "nm-sd-adapt.h", because they are either public
(in which case the adapter is not needed) or they are internal
(in which case they are themself included via a systemd source).
Sometimes, we must internal API (like "dhcp-lease-internal.h").
In this case, we also must include "nm-sd-adapt.h".
As the lldp API changed, adjust "nm-lldp-listener.c".
Note that the commit is not yet functional due to missing
sd_event_source_set_enabled() and sd_event_source_set_time().
Duplicated const specifiers are allowed by C99 and can easily
happen in macros. Also, systemd's interal code will use them.
Disable this warning, it doesn't seem useful.
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.
- 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
When NM tries to match a generated connection to a persistent one, it
considers also the metric of static routes. However, if the field is
set to -1 (use default value for the device) on the persistent
connection, the comparison will always fail because the generated
connection contains the actual value read from kernel.
To fix the issue, modify check_possible_match() to deal correctly with
-1 and translate it to the expected value for the current device when
performing the comparison.
This allows connections with static routes and default metric to
properly be re-assumed when NM is restarted.
https://bugzilla.redhat.com/show_bug.cgi?id=1302532
Seems that "dash" has issues with trap EXIT. This causes
test failures on systems where the default shell is not "bash".
[thaller@redhat.com: patch extracted from BZ and modified to
use bash everywhere]
https://bugzilla.gnome.org/show_bug.cgi?id=761146
Point in case:
# ip link add link dummy0 name dummy0.vlan type vlan id 4095
RTNETLINK answers: Numerical result out of range
This potentially causes existing (invalid) connections to disappear
as they now fail verification.
Instead of adjusting the range of the GObject property
NM_SETTING_VLAN_ID, reject it during vlan. This is a bit more
forgiving to an older client that isn't aware of this new restriction,
so he can first set the value without raising a critical warning.
Up to now, the "include" directory contained (only) header files that were
used project-wide by libs, core, clients, et al.
Since the directory now also contains a non-header file, the "include"
name is misleading. Instead of adding yet another directory that is
project-wide, with non-header-only content, rename the "include"
directory to "shared".
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
