This reverts commits 89e73ce86f and
543d2a4d45.
The commit assign "custom" to fixed DUID type 5. When making DUID fully
configurable, the type number should be also configurable. Also, the
fully custom DUID should be acceptable for DHCPv4.
Include T1 and T2 DHCPv6 options to expose in dbus API.
Introduced new field DHCPv6lease where these options are
added. This will be added to the JSON output when we query
org.freedesktop.network1.Manager object.
"static inline" makes sense in .h files. But in .c files it's useless
decoration, the compiler should just make its own decisions there, and
it can do that.
hence, replace all remaining uses of "static line" by a simple" static"
in all .c files (but keep them in .h files, where they make sense)
received
RFC4191 – Section 2.3 Route Information Option's Prf field:
If the Reserved (10) value is received, the Route Information Option MUST be ignored.
dhcp6_option_parse_string is intended to clear strings with length 0,
for consistency. The data assert is too strict for this purpose, so we
will allow data || data_len == 0, similar to other dhcp6_option_parse*
helpers.
Fixes: fde788601b ("dhcp6-client: parse RFC8910 captive portal dhcp6 option")
Oracle Cloud sends malformed DHCPv6 replies that have an invalid
byte at the end, which cannot be parsed as an option code.
networkd currently can cope with the invalid option (it is ignored),
but the whole packet is ignored altogether because of the additional
null at the end.
It's better to be liberal in what we accept and actually assign an
address, given that the reply contains a valid IA_NA.
Fixes#28183.
DHCP clients often send their own hostname in option 12. It can be useful
to store it with the lease so it can be shown to a human to easily identify
which lease belongs to which device.
RFC: https://www.rfc-editor.org/rfc/rfc2132#section-3.14
If we fail any allocation prior adding the lease to the server lease
hashmap.
==2103==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 128 byte(s) in 2 object(s) allocated from:
#0 0x4a203e in __interceptor_calloc /src/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:77:3
#1 0x4f6341 in calloc (/build/fuzz-dhcp-server+0x4f6341)
#2 0x4ec818 in add_lease /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-server.c:26:9
#3 0x4ec2bf in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/libsystemd-network/fuzz-dhcp-server.c:75:9
#4 0x4f68a8 in NaloFuzzerTestOneInput (/build/fuzz-dhcp-server+0x4f68a8)
#5 0x5158b3 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:611:15
#6 0x51509a in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool, bool*) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:514:3
#7 0x516769 in fuzzer::Fuzzer::MutateAndTestOne() /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:757:19
#8 0x517435 in fuzzer::Fuzzer::Loop(std::__Fuzzer::vector<fuzzer::SizedFile, std::__Fuzzer::allocator<fuzzer::SizedFile> >&) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:895:5
#9 0x50679f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:912:6
#10 0x507068 in LLVMFuzzerRunDriver /src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:925:10
#11 0x4f6b25 in main (/build/fuzz-dhcp-server+0x4f6b25)
#12 0x7f16084e3082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
DEDUP_TOKEN: __interceptor_calloc--calloc--add_lease
SUMMARY: AddressSanitizer: 128 byte(s) leaked in 2 allocation(s).
Found by Nallocufzz.
Recent gcc versions have started to trigger false positive
maybe-uninitialized warnings. Let's make sure we initialize
variables annotated with _cleanup_ to avoid these.
From RFC 2131 section 4.3.1 (https://www.rfc-editor.org/rfc/rfc2131#section-4.3.1):
----
The server MUST return to the client:
- Parameters requested by the client, according to the following rules:
-- IF the server has been explicitly configured with a default
value for the parameter, the server MUST include that value
in an appropriate option in the 'option' field,
----
The sentence is not only for ACK, but for all (positive) responses, that
is DHCPOFFER and DHCPACK.
Fixes#27471.
DHCP static leases are looked up by the client identifier as send by
the client, while configured based on MAC. As RFC 2131 states the client
identifier is an opaque key and must not be interpreted by the server
this means that DHCP clients can (/will) also use a client identifier
which is not a MAC address. One of these clients actually is
systemd-networkd which uses an RFC 4361 by default to generate the
client identifier. For these kind of DHCP clients static leases thus
don't work because of this mismatch between configuring a MAC address
but the server matching based on client identifier. This adds a fallback
to try to look up a configured static lease based on the "chaddr" of the
DHCP message as this will always contain the MAC address of the client.
Fixes#21368
Susant Sahani
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Yu Watanabe
Nandakumar Raghavan
David Tardon
Daan De Meyer
Luca Boccassi
Ronan Pigott
Philipp Kern
Rene Hollander
Frantisek Sumsal
Robert Meijers