The systemd DHCPv6 client requires a hardware address only to
determine the IAID; NM always overrides the IAID with its own and
therefore the hwaddr is not used.
Removing such requirement allows DHCPv6 to run over PPP, which is
useful with DHCPv6-PD to get a prefix from the ISP.
To test this, I set up a server with pppoe-server, radvd and the Wide
DHCPv6 server providing an address and a prefix. On the client, NM was
able to obtain a prefix using both dhcp=dhclient and dhcp=systemd.
Note that if there is no hardware address and you specify
ipv6.dhcp-duid=ll or ipv6.dhcp-iaid=mac, a warning will be emitted and
NM will use a random DUID/IAID.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/478
(cherry picked from commit 76a6a30577)
(cherry picked from commit 905d4eb36e)
g_clear_pointer() would always cast the destroy notify function
pointer to GDestroyNotify. That means, it lost some type safety, like
GPtrArray *ptr_arr = ...
g_clear_pointer (&ptr_arr, g_array_unref);
Since glib 2.58 ([1]), g_clear_pointer() is also more type safe. But
this is not used by NetworkManager, because we don't set
GLIB_VERSION_MIN_REQUIRED to 2.58.
[1] f9a9902aac
We have nm_clear_pointer() to avoid this issue for a long time (pre
1.12.0). Possibly we should redefine in our source tree g_clear_pointer()
as nm_clear_pointer(). However, I don't like to patch glib functions
with our own variant. Arguably, we do patch g_clear_error() in
such a manner. But there the point is to make the function inlinable.
Also, nm_clear_pointer() returns a boolean that indicates whether
anything was cleared. That is sometimes useful. I think we should
just consistently use nm_clear_pointer() instead, which does always
the preferable thing.
Replace:
sed 's/\<g_clear_pointer *(\([^;]*\), *\([a-z_A-Z0-9]\+\) *)/nm_clear_pointer (\1, \2)/g' $(git grep -l g_clear_pointer) -i
I think it's preferable to use nm_clear_g_free() instead of
g_clear_pointer(, g_free). The reasons are not very strong,
but I think it is overall preferable to have a shorthand for this
frequently used functionality.
sed 's/\<g_clear_pointer *(\([^;]*\), *\(g_free\) *)/nm_clear_g_free (\1)/g' $(git grep -l g_clear_pointer) -i
The GSource must also be unrefed. Also, first clear the field
before invoking callbacks to the upper layers.
Fixes: 843d696e46 ('dhcp: clean source on dispatch failure')
Fix the following warning:
NetworkManager[1524461]: Source ID 3844 was not found when attempting to remove it
g_logv (log_domain=0x7f2816fa676e "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=<optimized out>, args=args@entry=0x7ffe697374d0) at gmessages.c:1391
g_log (log_domain=log_domain@entry=0x7f2816fa676e "GLib", log_level=log_level@entry=G_LOG_LEVEL_CRITICAL, format=format@entry=0x7f2816fae240 "Source ID %u was not found when attempting to remove it") at gmessages.c:1432
g_source_remove (tag=519) at gmain.c:2352
nm_clear_g_source (id=<optimized out>) at ./shared/nm-glib-aux/nm-macros-internal.h:1198
dispose (object=0x55f7289b1ca0) at src/dhcp/nm-dhcp-nettools.c:1433
g_object_unref (_object=<optimized out>) at gobject.c:3303
g_object_unref (_object=0x55f7289b1ca0) at gobject.c:3232
dhcp4_cleanup (self=self@entry=0x55f728af3b20, cleanup_type=cleanup_type@entry=CLEANUP_TYPE_DECONFIGURE, release=release@entry=0) at src/devices/nm-device.c:7565
...
Fixes: 45521b1b38 ('dhcp: nettools: move to failed state if event dispatch fails')
nm_utils_is_valid_iface_name() is a public API of libnm-core, let's use
our internal API.
$ sed -i 's/\<nm_utils_is_valid_iface_name\>/nm_utils_ifname_valid_kernel/g' $(git grep -l nm_utils_is_valid_iface_name)
The _GET_PRIVATE() macros are all implemented based on
_NM_GET_PRIVATE(). That macro tries to be more type safe and uses
_Generic() to do the right thing. Explicitly casting is not only
unnecessary, it defeats these (static) type checks.
Don't do that.
Currently the DHCP client reports the BOUND state not only when the
lease is obtained initially but also when it is renewed. Having a
different state for the renewal will be used by NMDevice in the next
patch to determine whether the lease needs to be accept()ed or not.
and _nm_utils_inet6_ntop() instead of nm_utils_inet6_ntop().
nm_utils_inet4_ntop()/nm_utils_inet6_ntop() are public API of libnm.
For one, that means they are only available in code that links with
libnm/libnm-core. But such basic helpers should be available everywhere.
Also, they accept NULL as destination buffers. We keep that behavior
for potential libnm users, but internally we never want to use the
static buffers. This patch needs to take care that there are no callers
of _nm_utils_inet[46]_ntop() that pass NULL buffers.
Also, _nm_utils_inet[46]_ntop() are inline functions and the compiler
can get rid of them.
We should consistently use the same variant of the helper. The only
downside is that the "good" name is already taken. The leading
underscore is rather ugly and inconsistent.
Also, with our internal variants we can use "static array indices in
function parameter declarations" next. Thereby the compiler helps
to ensure that the provided buffers are of the right size.
The option is mandatory in the replies from server and so we don't
need to ask for it. dhclient doesn't do it either. But especially, it
seems that requesting the option causes some broken server
implementations to send duplicate instances of the option.
So, remove the option from the parameter request list of the internal
nettools and systemd DHCP implementation.
The 'retracted' event is emitted when the client receives a NAK in the
rebooting, requesting, renewing or rebinding state, while 'expired'
means that the client wasn't able to renew the lease before expiry.
In both cases the old lease is no longer valid and n-dhcp4 keep trying
to get a lease, so the two events should be handlded in the same way.
Note that the systemd client doesn't have a 'retracted' event and
considers all NAKs as 'expired' events.
If we know the address used previously, also tell the client to start
from the init-reboot phase, so that it will start with a DHCP request
instead of a discover.
Found by covscan:
NetworkManager-1.22.0/src/dhcp/nm-dhcp-nettools.c:945: check_return:
Calling "g_file_set_contents" without checking return value (as is
done elsewhere 16 out of 20 times).
Fixes: 9f89516928 ('dhcp: nettools: read/write lease files')
The abbreviations "ns" and "ms" seem not very clear to me. Spell them
out to nsec/msec. Also, in parts we already used the longer abbreviations,
so it wasn't consistent.
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
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.
RFC does not define how long the client ID can be. However,
n-dhcp4 enforces that the server replies with a client ID that
matches the request. Also, the client ID gets encoded as a DHCP
option, hence it cannot be longer than 255 bytes.
While n-dhcp4 doesn't enforce a certain length, a too long client
ID is not going to work. Hence, truncate it at 133 bytes.
This is the same limit that also systemd's DHCP client has. It's chosen
to fit an RFC4361-complient client ID with a DUID of length
MAX_DUID_LEN (which is 128 bytes according to RFC 3315 section 9.1).
Fixes-test: @ipv4_set_very_long_dhcp_client_id
See-also: https://github.com/nettools/n-dhcp4/pull/6https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/307
The hostname used for DHCP can be the one obtained from the hostnamed
service and is not guaranteed to be valid, at least with systemd
239. Instead of sending an invalid DHCP option to the server or
failing due to later checks in clients, ignore the hostname and log a
warning when it is invalid.
https://bugzilla.redhat.com/show_bug.cgi?id=1744427
Since commit 159ff23268 ('dhcp/dhclient-utils: skip over
dhclient.conf blocks') we skip blocks enclosed in lines containing '{'
and '}' because NM should ignore 'lease', 'alias' and other
declarations. However, conditional statements seem useful and should
not be skipped.
https://bugzilla.redhat.com/show_bug.cgi?id=1758550
Renamed the variable holding the compiler flags to be consistent
with different meson ports.
This naming pattern improves the use of different compiler flags
in environments with multiple languages.
The targets that involve the use of the `NetworkManager` library,
built in the `src` build file have been improved by applying a set
of changes:
- Indentation has been fixed.
- Set of objects used in targets have been grouped together.
- Aritificial dependencies used to group dependencies and custom
compiler flags have been removed and their use replaced with
proper dependencies and compiler flags to avoid any confussion.
The `nm-default.h` header is used widely in the code by many
targets. This header includes different headers and needs different
libraries depending the compilation flags.
A new set of `*nm_default_dep` dependencies have been created to
ease the inclusion of different directorires and libraries.
This allows cleaner build files and avoiding linking unnecessary
libraries so this has been applied allowing the removal of some
dependencies involving the linking of unnecessary libraries.
Add support to the internal DHCP client for requesting a prefix and
distributing it to interfaces with 'shared' IPv6 mode.
The systemd-networkd API currently allows to request only a single
prefix and so there will be issues when the number of downstream
interfaces is greater than the number of /64 subnets available in the
returned prefix; but this is still an improvement over the previous
situation when no prefix was requested at all.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/247
nettools does not expose the original lease lifetime. It's a missing
API. Instead, it only exposes the timestamp when the lease will expire.
As a workaround, we calulate the timestamp by subtracting the current
timestamp from the expiration timestamp, assuming that the lease was
received just now. However, it was not received *exactly* now, but a
few milliseconds before. Hence, the calculated timestamp is not exact
here and likely a few milliseconds less then the actual (full integer)
value.
Account for that by rounding the value to the second.
