Instead of terminating the program when the dispatch function returns
an invalid return code, log an error message and convert the error
code to a valid, generic one.
https://bugs.archlinux.org/task/64880
After t1, the client tries to renew the lease by contacting via the
udp socket the server specified in the server-id option. If this
fails, after t2 it tries to contact any server using broadcast. For
this to work, the packet socket must be used.
Currently the client always starts from the INIT state (i.e. sending a
discover message). If a requested-ip was specified by the caller, it
is added as an option in the discover.
It was reported that some DHCP servers don't respond to discover
messages with the requested-ip option set [1][2].
The RFC allows to skip the discover by entering the INIT-REBOOT state
and starting directly with a broadcast request message containing the
requested IP address. Implement that.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1781856
[2] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/310
RHEL7 supports clock_gettime(CLOCK_BOOTIME), but it does not support
timerfd_create(CLOCK_BOOTIME). Creating a timerfd will fail with EINVAL.
Fallback to CLOCK_MONOTONIC.
Compare this to n-acd which also has compatibility code to fallback to
CLOCK_MONOTONIC. However when n-acd falls back to CLOCK_MONOTONIC, it uses
monotonic clock also for clock_gettime().
For n-dhcp4, the timestamps are also exposed in the public API
(n_dhcp4_client_lease_get_lifetime()). Hence, for timestamps n-dhcp4
still uses and requires clock_gettime(CLOCK_BOOTIME). Only the internal
timeout handling with the timerfd falls back to CLOCK_MONOTONIC.
https://github.com/nettools/n-dhcp4/pull/13https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/362
(cherry picked from commit a1771c738d)
Otherwise, other applications cannot bind to port 0.0.0.0:68 at the same time.
This is for example what dhclient wants to do. So even when running
dhclient on another, unrelated interface, it would fail to bind the UDP
socket and quit.
Note that also systemd-networkd's DHCPv4 client sets this socket option.
Presumably for the same reasons.
Signed-off-by: Thomas Haller <thaller@redhat.com>
https://github.com/nettools/n-dhcp4/pull/12
(cherry picked from commit 53b74bc614)
In some cases it is useful to have the library log what it is doing
for debugging purposes; add a simple API that allows setting a
syslog-style logging level and specifying a logging function.
https://github.com/nettools/n-dhcp4/pull/8
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
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.
When we build n-dhcp4 for NetworkManager we get a compiler warning.
This can also be reproduced by building n-dhcp4 alone:
$ CFLAGS='-Werror=declaration-after-statement' meson build && ninja -C build
...
[36/47] Compiling C object 'src/25a6634@@ndhcp4-private@sta/n-dhcp4-outgoing.c.o'.
FAILED: src/25a6634@@ndhcp4-private@sta/n-dhcp4-outgoing.c.o
ccache cc -Isrc/25a6634@@ndhcp4-private@sta -Isrc -I../src -Isubprojects/c-list/src -I../subprojects/c-list/src -Isubprojects/c-siphash/src -I../subprojects/c-siphash/src -Isubprojects/c-stdaux/src -I../subprojects/c-stdaux/src -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -g -D_GNU_SOURCE -Werror=declaration-after-statement -fPIC -fvisibility=hidden -fno-common -MD -MQ 'src/25a6634@@ndhcp4-private@sta/n-dhcp4-outgoing.c.o' -MF 'src/25a6634@@ndhcp4-private@sta/n-dhcp4-outgoing.c.o.d' -o 'src/25a6634@@ndhcp4-private@sta/n-dhcp4-outgoing.c.o' -c ../src/n-dhcp4-outgoing.c
../src/n-dhcp4-outgoing.c: In function ‘n_dhcp4_outgoing_new’:
../src/n-dhcp4-outgoing.c:63:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
63 | static_assert(N_DHCP4_NETWORK_IP_MINIMUM_MAX_SIZE >= N_DHCP4_OUTGOING_MAX_PHDR +
| ^~~~~~~~~~~~~
(cherry picked from commit 9e7ca3e091)
The probe takes a reference to the current lease and so it must
release it upon destruction.
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
https://github.com/nettools/n-dhcp4/pull/1
In particular, avoid including linux/netdevice.h from headers. This is
not a problem on newer distros, but required for CentOS 7.6.
Signed-off-by: Tom Gundersen <teg@jklm.no>
