After b2851e8d62, if IAID and DUID are not
set on start, calling sd_dhcp_client_set_iaid_duid_en() in
client_message_init() triggers assertion, as the client is already
running at the stage. Let's set IAID and DUID earlier.
Fixes#28990.
Previously, DHCP_STATE_STOPPED and DHCP_STATE_INIT are both handled as
not-running. Moreover, previously after sd_dhcp_client_start() is
called, the client still in INIT state (and thus handled as not-running)
even if its internal timer event sources are initialized.
Let's make only STOPPED state handled as not-running, and make the
client initially in STOPPED state.
Prompted by #28896.
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.
pelaufer
Yu Watanabe
Susant Sahani
Luca Boccassi
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Nandakumar Raghavan
David Tardon
Daan De Meyer
Ronan Pigott
Philipp Kern
Rene Hollander
Frantisek Sumsal