| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
network: dhcp-server: allow to specify server address for DNS= or friends
|
| | |
|
| |
| |
| |
| | |
Closes #15026.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Follow-up for 59aa622013277cfe6349d0789a7a00ad2b884902.
|
|\ \
| | |
| | | |
resolved: misc. small DnsStream refactors and improvements
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since test-resolved-stream brings up a simple DNS server on 127.0.0.1:12345,
only one instance could run at a time, so it would fail when run like
`meson test -C build test-resolved-stream --repeat=1000`.
Similarly, if by chance something is up on port 12345, the test would fail.
To make the test more reliable, run it in an isolated user + network namespace.
If this fails (some distributions disable user namespaces), just run as before.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In commit 2aaf6bb6e99b0f2bd73e0c49bef9e11a2844bf1a, an issue was fixed where
systemd-resolved could get stuck for multiple seconds waiting for incoming data,
since GnuTLS/OpenSSL can buffer a TLS record, so data could be available, but
no EPOLLIN event would be generated.
To fix this, a somewhat elaborate logic consisting on asking the TLS library
whether it had buffered data, then "faking" an EPOLLIN event was implemented.
However, there is a much simpler solution: Always read as much data as available
(i.e. until we get an event like EAGAIN when trying to read) from the stream
when we get an EPOLLIN event, instead of at most a single packet per event.
This approach does not require asking the TLS library whether it has buffered
data, and the logic is exactly the same for both the TCP and TLS case.
test-resolved-stream is fixed to avoid a latent double free bug.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the DoT case, dns_stream_writev decomposed an iovec into multiple
dnstls_stream_write calls, which resulted in multiple SSL writes and multiple
TLS records. This can be checked from a network capture, e.g. using socat:
socat -v -x openssl-listen:853,reuseaddr,fork,cert=my.cert,key=my.key,verify=0 openssl:8.8.8.8:853
Instead, propagate the iovec as-is into the DoT handling code. For GnuTLS, the
library provides support for buffering ('corking') a record. OpenSSL has no
such facility, so we join the iovec into a single buffer then call SSL_write.
socat capture of `resolvectl -4 query --cache=no example.com` before the commit:
> 2022/01/30 13:35:52.194200 length=2 from=0 to=1
00 28 .(
--
> 2022/01/30 13:35:52.194253 length=40 from=2 to=41
1e b2 01 00 00 01 00 00 00 00 00 01 07 65 78 61 .............exa
6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 00 29 mple.com.......)
ff e4 00 00 00 00 00 00 ........
--
< 2022/01/30 13:35:52.232798 length=58 from=0 to=57
00 38 1e b2 81 80 00 01 00 01 00 00 00 01 07 65 .8.............e
78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 c0 xample.com......
0c 00 01 00 01 00 00 53 6f 00 04 5d b8 d8 22 00 .......So..]..".
00 29 02 00 00 00 00 00 00 00 .)........
socat capture of `resolvectl -4 query --cache=no example.com` after the commit:
> 2022/01/30 13:34:47.598099 length=42 from=504 to=545
00 28 37 86 01 00 00 01 00 00 00 00 00 01 07 65 .(7............e
78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 00 xample.com......
00 29 ff e4 00 00 00 00 00 00 .)........
--
< 2022/01/30 13:34:47.613203 length=58 from=756 to=813
00 38 37 86 81 80 00 01 00 01 00 00 00 01 07 65 .87............e
78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00 01 c0 xample.com......
0c 00 01 00 01 00 00 52 5e 00 04 5d b8 d8 22 00 .......R^..]..".
00 29 02 00 00 00 00 00 00 00 .)........
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since when handling a DNS over TLS stream, the TLS library can override the
requested events through dnstls_events for handshake/shutdown purposes,
obtaining the event flags through sd_event_source_get_io_events and checking
for EPOLLIN or EPOLLOUT does not really tell us whether we want to read/write
a packet. Instead, it could just be OpenSSL/GnuTLS doing something else.
To make the logic more robust (and simpler), save the flags that tell us
whether we want to read/write a packet, and check them instead of the IO flags.
(& use uint32_t for the flags like in sd_event_source_set_io_events prototype)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a follow-up for d5ee050ffc9d413253932d9340ade8c8fb111092, and
reintroduces a requirement dep from systemd-journal-flush.service onto
systemd-journald.service, but a weaker one than originally: a Wants= one
instead of a Requires= one.
Why? Simply because the service issues an IPC call to the journald,
hence it should pull it in. (Note that socket activation doesn't happen
for the Varlink socket it uses, hence we should pull in the service
itself.)
|
|\ \ \
| | | |
| | | | |
sd-dhcp-lease: two fixes
|
| | | |
| | | |
| | | |
| | | | |
Fixes https://github.com/systemd/systemd/pull/22294#issuecomment-1024840811.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The destination address was read twice, one is for prefixlen, and
other is for destination address itself. And for prefixlen, the address
might be read from unaligned buffer.
This also modernizes the code.
|
|\ \ \ \
| | | | |
| | | | | |
efi: add/user assert_se()/ASSERT_SE_PTR() for OOM handling
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
ASSERT_SE_PTR() is like ASSERT_PTR() but uses assert_se() instead of
assert() internally.
Code should use ASSERT_SE_PTR() where the check should never be
optimized away, even if NDEBUG is set.
Rationale: assert() is the right choice for validating assumptions about
our own code, i.e. checking conditions that are "impossible" to not
hold, because we ourselves hacked things up the "right" way of course.
assert_se() is the right choice for tests that come with a weaker
guarantee, they encode assumptions over other's API behaviour, i.e.
whether something can fail there or not.
When developing tools that are not oom-safe assert_se() is the right
choice: we know that on Linux OOM doesn't really happen, even though
theoretically the API allows it to happen.
Usecase for ASSERT_SE_PTR() is mostly the fatal memory allocation logic
for EFI memory allocations. So far it used regular assert() i.e. OOM
failurs would be totally ignored if NDEBUG is set. We'd rather have our
EFI program to print an assert message and freeze instead though.
|
| | | | | |
|
| |_|/ /
|/| | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
pid1: pam_end() PAM_DATA_SILENT fix
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes: #22318
|
| |/ / /
|/| | |
| | | |
| | | |
| | | | |
It's a good idea that we validate argc/argv when we are supposed to
store them away.
|
|\ \ \ \
| |/ / /
|/| | | |
network: xfrm: refuse zero interface ID
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This also unifies two tests for xfrm, and checks the output of
'ip link' command.
Fixes #22329.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since kernel 5.17-rc1, 5.16.3, and 5.15.17 (more specifically,
https://github.com/torvalds/linux/commit/8dce43919566f06e865f7e8949f5c10d8c2493f5)
the kernel refuses to create an xfrm interface with zero ID.
|
| |_|/
|/| |
| | |
| | | |
address
|
|\ \ \
| | | |
| | | | |
sd-dhcp-server: remove lease with hashmap_remove_value()
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
non-matching clients
This fix the root cause of the issue #22253.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
the client ID exists
|
| | | |
| | | |
| | | |
| | | | |
As, the value of pool_offset is not used.
|
| | | |
| | | |
| | | |
| | | | |
And logs error in the function.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Otherwise, if the second push is failed, then the first hashmap contains
dirty entry.
Also, this makes hashmap_remove_value() used when removing leases to
make not wrong lease is removed from the hashmap.
Note, this just hide the root cause of the issue #22253, which will be
fixed in later commit.
Fixes #22253.
|
| | | | |
|
| | | | |
|
| | | | |
|