- systemd-networkd and initscripts both support it.
- it seems suggested to configure routes with scope "link" on AWS.
- the scope is only supported for IPv4 routes. Kernel ignores the
attribute for IPv6 routes.
- we don't support the aliases like "link" or "global". Instead
only the numeric value is supported. This is different from
systemd-networkd, which accepts names like "global" and "link",
but no numerical values. I think restricting ourself only to
the aliases unnecessarily limits what is possible on netlink.
The alternative would be to allow aliases and numbers both,
but that causes multiple ways to define something and has
thus downsides. So, only numeric values.
- when setting rtm_scope to RT_SCOPE_NOWHERE (0, the default), kernel
will coerce that to RT_SCOPE_LINK. This ambiguity of nowhere vs. link
is a problem, but we don't do anything about it.
- The other problem is, that when deleting a route with scope RT_SCOPE_NOWHERE,
this acts as a wild care and removes the first route that matches (given the
other route attributes). That means, NetworkManager has no meaningful
way to delete a route with scope zero, there is always the danger that
we might delete the wrong route. But this is nothing new to this
patch. The problem existed already previously, except that
NetworkManager could only add routes with scope nowhere (i.e. link).
There is an "info" part and a part with the data that we parsed.
Don't track the static and mutable data in the same variable.
Also, this allows to mark the static part as "const static".
In the past, kernel (and NetworkManager) did not support the onlink
flags for IPv6 routes. That is no longer the case.
Fixes: f5e8bbc8e0 ('libnm,core: enable "onlink" flags also for IPv6 routes')
Previously, our "internal" DHCPv4 client is based on a fork of
systemd code. This manner of maintaining the fork is problematic.
The solution is to use a proper library: n-dhcp4 from the nettools
project.
We already have these two as undocumented plugins available, by
setting either "dhcp=systemd" or "dhcp=nettools". This is only for
testing. Users are only supposed to use the "internal" plugin.
Up until now, the "internal" DHCPv4 plugin was based on "systemd" code.
Change that to use "nettools" instead.
Possibly this breaks something, and we need to fix it. But do this
early so we have time to test the nettools plugin and identify issues.
For the user, this change should be entirely transparant.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/302
We preferably should use our convenience macros like _LOGD().
Since those macros expand to _NMLOG() (which needs to be defined
separately), we can move it to "nm-logging-fwd.h" and reuse.
I guess, if you write portable applications, then GIOChannel makes a lot of sense.
But we know that this is on Linux. We don't need to pretend that we
cannot poll on the file descriptor directly.
Curl documents about CURLMOPT_TIMERFUNCTION:
The timer_callback will only be called when the timeout expire time is
changed.
That means, we should not cancel the timeout when it happend, but
only when the callback is called again (or during cleanup).
See-also: https://curl.haxx.se/libcurl/c/CURLMOPT_TIMERFUNCTION.html
svUnsetValue (ifcfg, KEY);
if (condition)
svSetValue* (ifcfg, KEY, ...);
is not good. It requires first clearing the value, before setting
it again.
Various cleanup to fix such uses.
Add a new 'carrier' flag to the InterfaceFlags property of devices to
indicate the current carrier state.
The new flag is equivalent to the 'lower-up' flag for all devices
except the ones that use a non-standard carrier detection mechanism
like NMDeviceAdsl.
Add a new read-only "InterfaceFlags" property to the Device interface
to export via D-Bus kernel flags and possibly other NM specific
flags. At the moment IFF_UP and IFF_LOWERUP are implemented.
After we set link parameters (auto-negotiation, speed, duplex) in
stage1, the carrier can go down for several seconds because the
Ethernet PHY needs to renegotiate the link. Wait that carrier goes up
before starting the supplicant or the EAPoL start packet can be lost
causing an authentication failure.
https://bugzilla.redhat.com/show_bug.cgi?id=1759797
[user] are arbitrary strings that can be attached to a connection.
NetworkManager itself does not care about them, they are only here
for other applications.
Allow reapplying changes to the user setting. Usually the reason to
reject reapplying a setting is because it's either not implemented
or not possible to change (without a full reactivation of the device).
In this case there is nothing to implement, and of course it's possible
to do so.
Now that we can not only get the expiry timestamp of the lease
(n_dhcp4_client_lease_get_lifetime()), but also the base timestamp,
we can calculate the lifetime exactly.
Previously, we had to guess the base time by assuming that we just
received the lease *now*. This wasn't exact.
The "expiry" is the Unix timestamp when the lease expires.
This is not at all a useful parameter, in particular because
the system's clock can be reset. Instead, we should expose
the lease receive time stamp (in CLOCK_BOOTTIME), and the lease
lifetime.
Anyway. So, we somehow need to express infinite lifetimes. Previously,
we would use the special value 4294967295 (2^32-1). However, that value
does not seem so great, because it's also the Unix timestamp of
2106-02-07T06:28:15+0000. While that is quite far in the future, it's
a valid timestamp still. Of course, the code worked around that by never
setting a timestamp larger than 4294967295-1, but it still limits the
range of what we can expose.
Note that for the lifetime "dhcp_lease_time", we do express infinity
with 4294967295. That's fine, it also does not contradict what we
receive in the DHCP lease on the wire because the lifetime there is
expressed by a 32 bit integer.
Instead, for the "expiry" timestamp, don't perform such triming.
The expiry timestamp is just the start timestamp plus the lease
lifetime. If that is larger than 2106-02-07, so be it.
On the other hand, express infinity by omitting the "expiry" field.
It is really not clear what the user could have meant by specifying a
bootdev= argument, and we deal with it just by ensuring a device with
that name whould come up.
We therefore pick a default connection if there's one (that is a
conneciton that we create if the device name is unspecified, as in
"ip=auto"), otherwise we create a new one.
In nm_acd_manager_announce_addresses() we should not only start the
probes but also add the acd file descriptor to the main loop.
Otherwise, a timer is armed to send the announcements but it never
fires and no announcements are sent.
Fixes: d9a4b59c18 ('acd: adapt NM code and build options')
https://bugzilla.redhat.com/show_bug.cgi?id=1767681
