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.
Currently in any of the BOUND, RENEWING and REBINDING states the probe
checks the expiration of T1, T2 and lifetime. This is not correct
because, for example, if the timer fires in the RENEWING state, the
probe must not transition to RENEWING again (i.e. check again that
now >= T1). Note that there is no guarantee that the timer triggers
exactly once for T1, T2 and lifetime expirations because the timer is
also used for the retransmission logic in NDhcp4CConnection.
Therefore, add some checks to ensure that only correct transitions are
allowed.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/341https://bugzilla.redhat.com/show_bug.cgi?id=1773456
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.
Import the downstream addition for lease-time [1].
These are not merged upstream yet, but let's use
the patches already. If the patches that get merged
upstream eventually differ, we still can adjust our fork
easily.
[1] https://github.com/nettools/n-dhcp4/pull/5
The API already had n_dhcp4_client_lease_get_lifetime(), which is the CLOCK_BOOTTIME
when the lease expires (or ((uint64_t)-1)). But it might be interesting to
know the actual lease duration and when the lease was received (and the
time started to count).
Expose an API for that. With this, one can also calculate the original, exact lease
lifetime, by subtracting n_dhcp4_client_lease_get_basetime() from n_dhcp4_client_lease_get_lifetime(),
while taking care of ((uint64_t)-1).
First of all, from the naming of n_dhcp4_incoming_query_u32() it is
confusing to coerce 0xFFFFFFFF to zero. It should just return the
plain value.
Also note that n_dhcp4_incoming_query_u32() only has three callers:
n_dhcp4_incoming_query_lifetime(), n_dhcp4_incoming_query_t1() and
n_dhcp4_incoming_query_t2().
Looking further, those three functions only have one caller:
n_dhcp4_incoming_get_timeouts(). Note how the code there already tries
to handle UINT32_MAX and interprets it as infinity (UINT64_MAX).
But as it was, UINT32_MAX never actually was returned.
It seems that RFC [1] does not specially define the meanings of
0xFFFFFFFF and 0. It sounds reasonable to assume that 0 just means
0 lifetime, and 0xFFFFFFFF means infinity. On the other hand, compare
this to systemd's code [2], which coerces 0 to 1. This does not seem
right to me though. Note how systemd returns 0xFFFFFFFF as-is.
Drop the special handling of 0xFFFFFFFF from n_dhcp4_incoming_query_u32().
It now just returns the plain value and it's up to n_dhcp4_incoming_get_timeouts()
to make sense of that. This will fix behavior, so that 0xFFFFFFFF will be
reported as infinity, and not as zero.
[1] https://tools.ietf.org/html/rfc2132#section-9.2
[2] 68c2b5ddb1/src/libsystemd-network/sd-dhcp-lease.c (L553)
It is error prone when a function consumes an input only in certain
cases (and telling the caller via the return code). At least in these
cases, the message is never used afterwards, and we can always pass
it on.
libnm has a dependency on 'libnmdbus_dep', which contains 'link_with:
libnmdbus'. This however only enforces that libnm is linked after the
libnmdbus static library is built; it doesn't give any guarantees
about the compilation phase.
We need to make libnm compilation depend on the generated header
files. The output of 'gnome.gdbus_codegen' is an array with the header
file in the second position; use it to add a proper
dependency. Unfortunately this works only with meson >= 0.46.
In the future libnm will no longer use gdbus generated code and this
dependency will not be needed anymore.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/286
This essentially aligns the implementation with the documentation.
It is also rather useful, since it allows us to use the value returned
by nm_setting_wired_get_mac_address() directly, and that one can indeed
be NULL.
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.
We need to actually read the stdout/stderr of the nmcli programs.
Otherwise, the pipe might fill uup and block to process (eventually
leading to timeout).
