| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Follow-up for a39a9ac8065c29330207838b70fe388bde2bc254.
|
| |
|
| |
|
|\
| |
| | |
Split/rename util.c+h and def.h
|
| |
| |
| |
| |
| |
| | |
The name "def.h" originates from before the rule of "no needless abbreviations"
was established. Let's rename the file to clarify that it contains a collection
of various semi-related constants.
|
| |
| |
| |
| |
| | |
util.h is now about logarithms only, so we can rename it. Many files included
util.h for no apparent reason… Those includes are dropped.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I changed imports of util.h to initrd-util.h, or added an import of
initrd-util.h, to keep compilation working. It turns out that many files didn't
import util.h directly.
When viewing the patch, don't be confused by git rename detection logic:
a new .c file is added and two functions moved into it.
|
|/
|
|
|
|
|
| |
This helps in avoiding compiling errors on musl. Definition of
IFF_LOOPBACK is the reason for including linux/if_arp.h, this however
could be obtained from net/if.h glibc header equally and makes it
portable as well.
|
|\
| |
| | |
wait-online: support alternative interface names
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
No functional changes, just refactoring and preparation for later
commits.
|
| | |
|
|/
|
|
|
|
|
| |
Previously, interfaces are partially reconfigured in a spurious way.
Let's use the same way as `networkctl reconfigure`.
Hopefully fixes #14987 and #24997.
|
|\
| |
| | |
network: reconfigure interface when renamed
|
| |
| |
| |
| |
| |
| |
| |
| | |
When at least one of the name, MAC address, udev properties, and so on
for an interface is updated, try to find a matching .network file, and
reconfigure if a new .network file is assigned.
Fixes #24975.
|
| |
| |
| |
| |
| |
| |
| |
| | |
No functional changes, just refactoring and preparation for later
commits.
Note, `link->dev` should always exist when link state is initialized or
later.
|
| |
| |
| |
| |
| |
| |
| |
| | |
We have already allowed to reconfigure failed interface manually, but
not allowed to do automatically, e.g. on carrier gain.
This makes that failed interfaces also reconfigured automatically.
Note, the condition is inversed to shorten the condition.
|
| |
| |
| |
| |
| | |
The function `link_reconfigure_impl()` has the same condition at the
beginning.
|
| |
| |
| |
| |
| |
| |
| | |
Otherwise, the slave interface may go down, especially when the master
is bond.
Fixes #25067.
|
|\ \
| | |
| | |
| | |
| | | |
yuwata/network-fix-race-in-device-renaming-vs-dhcp
network,dhcp: fix theoretical race in device renaming
|
| | |
| | |
| | |
| | | |
The attached sd_device object will be used later.
|
|\ \ \
| | | |
| | | | |
network: adjust route metric based on router preference
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
Even if different preference is specified, the kernel merges multiple
routes with the same preference. This is problematic when a network has
multiple routers.
Fixes #25138.
|
|\ \ \
| | | |
| | | | |
network: fix handling of route table 0
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
Fixes #25089.
|
| |/ / |
|
|/ / |
|
|/
|
|
|
|
|
| |
Follow-up for 778e3da95ef16302956087e6f10ccf7d42499aec.
These settings are saved only when a .network file is assigned to the
interface. Let's silence noisy logs for unmanaged interfaces.
|
|
|
|
|
|
|
|
| |
(s) is just ugly with a vibe of DOS. In most cases just using the normal plural
form is more natural and gramatically correct.
There are some log_debug() statements left, and texts in foreign licenses or
headers. Those are not touched on purpose.
|
|\
| |
| | |
Erradicate strerror
|
| |
| |
| |
| | |
https://github.com/systemd/systemd/pull/24933#discussion_r991242789
|
| |
| |
| |
| |
| | |
Though, it should be already freed already freed in link_stop_engines()
-> ndisc_stop(). Just for safety.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
After the commit 773024685b37170395a11716f8e4ad99d3580455, DNS servers
or domains are dropped when their lifefime become zero. Hence, it is not
necessary to try to them when writing state file.
Of course, because of the accuracy of the timer event source or priority
of event sources, a possibility is introduced that a DNS server or domain
with zero lifetime is stored in the state file. However, such entry will
be dropped soon when the timer event source is triggered. Hence, that
should not cause any real issues.
|
| |
| |
| |
| |
| | |
If there exists multiple routers, then the previous logic may introduce
too many DNS servers or domains.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
received
Routers may send options with zero lifetime if previously announced
information is outdated. Hence, if we receive such messages, then we
need to drop relevant addresses or friends.
See e.g. https://www.rfc-editor.org/rfc/rfc4861#section-12.
Follow-up for 2ccada8dc4a3571468a335808fd6fe49b8c6c6dd.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Zero lifetime in RA is special, and we should not assign possibly very
short lifetime addresses or friends.
This should not change anything at least now, preparation for later
commits. Note, DHCPv4 and v6 code also uses it, but sd-dhcp-client and
sd-dhcp6-client already filtered messages with zero lifetime. Hence,
the change should not affect DHCP code.
|
| |
| |
| |
| |
| | |
Otherwise, settings based on previously received RA messages will never
removed without receiving a new RA message.
|
| |
| |
| |
| |
| |
| |
| | |
Otherwise, e.g. if a router is replaced, then the previously received
settings may never dropped.
Follow-up for 2ccada8dc4a3571468a335808fd6fe49b8c6c6dd.
|
| |
| |
| |
| |
| | |
After the commit 3b6a3bdebfb555754fdc6ee507e3f6964de7b61c, address_get()
does not return 1.
|
| |
| |
| |
| | |
Preparation for later commits.
|
| |
| |
| |
| | |
See https://www.rfc-editor.org/rfc/rfc4861#section-4.6.2.
|
|/
|
|
| |
No functional changes.
|
|
|
|
|
|
|
|
| |
If the lifetime of the route is already expired, do not try to
configure it.
Fixes a use-after-free, as the Request object is already freed, thus, we
cannot use Route or Link stored in Request object.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IPv6 Neighbor Discovery lets us autoconfigure a link's IPv6 addresses,
routes, DNS servers, and DNS search domains by listening for Router
Advertisement (RA) packets broadcast by one or more routers on the link.
Each RA can contain zero or more "options," each describing one piece of
configuration (e.g. a single route).
Currently, when we receive an RA from a router, we delete any addresses,
routes, etc. that originated from that router's previous RAs unless
they're also present as options in the new RA.
That behavior is a violation of RFC 4861[1]. In Section 9, the RFC
states that
Senders MAY send a subset of options in different packets. ... Thus,
a receiver MUST NOT associate any action with the absence of an
option in a particular packet. This protocol specifies that
receivers should only act on the expiration of timers and on the
information that is received in the packets.
Several other passages in the RFC reiterate this. Section 6.2.3:
A router MAY choose not to include some or all options when sending
unsolicited Router Advertisements.
Section 6.3.4:
Hosts accept the union of all received information; the receipt of a
Router Advertisement MUST NOT invalidate all information received in
a previous advertisement or from another source.
At least one consumer router in production today, the Google Nest Wifi,
often sends RAs that omit its global IPv6 prefix. When current versions
of systemd-networkd receive those RAs, they immediately delete the
interface's global IPv6 address, which breaks IPv6 connectivity.
Fix the issue by removing the invalidation logic entirely. It's not
needed at all, since we already invalidate addresses, routes, and DNS
configuration when the interface goes down or their lifetimes expire.
This fix does have the side effect of preventing changes to the .network
file (e.g. denylisted prefixes, whether to add routes from RAs) from
taking effect as soon as a new RA arrives. Instead, a full interface
reconfiguration is needed. But triggering those changes on RA receipt
was already rather arbitrary and out of the administrator's control, so
I think this change is fine.
commit 69203fba700e ("network: ndisc: remove old addresses and routes
after at least one SLAAC address becomes ready") introduced this
behavior. commit 50550722e3ba fixed it partially, by preventing one
router's RAs from invalidating another router's configuration.
[1] https://www.rfc-editor.org/rfc/rfc4861
Fixes: 69203fba700e ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
|
|\
| |
| | |
sd-network: several cleanups
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This drops spurious lines in `networkctl status` for unmanaged interfaces.
Before:
```
$ networkctl status --lines 0 lo
● 1: lo
Link File: n/a
Network File: n/a
Type: loopback
State: carrier (unmanaged)
Online state: unknown
HW Address: 00:00:00:00:00:00
MTU: 65536
QDisc: noqueue
IPv6 Address Generation Mode: eui64
Queue Length (Tx/Rx): 1/1
Address: 127.0.0.1
::1
Activation Policy: up
Required For Online: yes
```
After:
```
$ networkctl status --lines 0 lo
● 1: lo
Link File: n/a
Network File: n/a
State: carrier (unmanaged)
Online state: unknown
Type: loopback
Hardware Address: 00:00:00:00:00:00
MTU: 65536
QDisc: noqueue
IPv6 Address Generation Mode: eui64
Number of Queues (Tx/Rx): 1/1
Address: 127.0.0.1
::1
```
That is, the lines for Activation Policy and Required For Online are
dropped.
|