Commit Graph
335 Commits
Author SHA1 Message Date
Ronan Pigott edb88a7201 network: Introduce UseCaptivePortal DHCPv4 option
Accepts a boolean. When enabled, UseCaptivePortal will request and
retain the captive portal configuration from the DHCP server.
2023-07-02 01:13:43 -07:00
Tuetuopay 1d84a3c779 network/dhcp4: accept local subnet routes from DHCP
RFC3442 specifies option 121 (Classless Static Routes) that allow a DHCP
server to push arbitrary routes to a client. It has a Local Subnet
Routes section expliciting the behavior of routes with a null (0.0.0.0)
gateway.

Such routes are to be installed on the interface with a Link scope, to
mark them as directly available on the link without any gateway.

Networkd currently drops those routes, which is against the RFC, as
Linux has proper support for such routes.

Fixes: 7f20627 ("network: dhcp4: ignore gateway in static routes if destination is link-local or in the same network")
2023-01-31 23:58:34 +00:00
Yu Watanabe f95fb19922 network: introduce QuickAck= for [DHCPv4] and [IPv6AcceptRA]
Closes #25906.
2023-01-16 14:40:22 +09:00
chris ea57796854 optionally set socket priority on DHCPv4 raw socket 2023-01-12 13:26:47 +09:00
Yu Watanabe 3b1dbdf0c2 network: attach device to DHCP clients
The attached sd_device object will be used later.
2022-10-26 08:08:35 +09:00
Thomas Hebb 2ccada8dc4 network: don't forget old RAs when a new one arrives
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 69203fba70 ("network: ndisc: remove old addresses and routes
after at least one SLAAC address becomes ready") introduced this
behavior. commit 50550722e3 fixed it partially, by preventing one
router's RAs from invalidating another router's configuration.

[1] https://www.rfc-editor.org/rfc/rfc4861

Fixes: 69203fba70 ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
2022-10-03 09:59:37 +09:00
David Tardon 995340074e tree-wide: use ASSERT_PTR more 2022-09-13 08:13:27 +02:00
Topi Miettinen 4b3590c324 network: NetLabel integration
New directive `NetLabel=` provides a method for integrating static and dynamic
network configuration into Linux NetLabel subsystem rules, used by Linux
Security Modules (LSMs) for network access control. The label, with suitable
LSM rules, can be used to control connectivity of (for example) a service with
peers in the local network. At least with SELinux, only the ingress can be
controlled but not egress. The benefit of using this setting is that it may be
possible to apply interface independent part of NetLabel configuration at very
early stage of system boot sequence, at the time when the network interfaces
are not available yet, with netlabelctl(8), and the per-interface configuration
with systemd-networkd once the interfaces appear later.  Currently this feature
is only implemented for SELinux.

The option expects a single NetLabel label. The label must conform to lexical
restrictions of LSM labels. When an interface is configured with IP addresses,
the addresses and subnetwork masks will be appended to the NetLabel Fallback
Peer Labeling rules. They will be removed when the interface is
deconfigured. Failures to manage the labels will be ignored.

Example:
```
[DHCPv4]
NetLabel=system_u:object_r:localnet_peer_t:s0
```

With the above rules for interface `eth0`, when the interface is configured with
an IPv4 address of 10.0.0.123/8, `systemd-networkd` performs the equivalent of
`netlabelctl` operation

```
$ sudo netlabelctl unlbl add interface eth0 address:10.0.0.0/8 label:system_u:object_r:localnet_peer_t:s0
```

Result:
```
$ sudo netlabelctl -p unlbl list
...
 interface: eth0
   address: 10.0.0.0/8
    label: "system_u:object_r:localnet_peer_t:s0"
...
```
2022-08-29 14:23:17 +09:00
Yu Watanabe 7fddb9704f dhcp4: stop client before updating MAC address 2022-08-06 04:53:36 +09:00
Yu Watanabe 4b482e8bf4 network: check link state with link_is_ready_to_configure() before configuring DHCP client or friends
Otherwise, DHCP client or friends may started before link-layer properties,
e.g. MAC address, being configured or the link being activated.
2022-08-05 21:49:27 +09:00
Yu Watanabe 2d3d0e8f7d network: drop doubled semicolon 2022-08-02 02:44:37 +09:00
Yu Watanabe 8de56fb3e0 network: rename Link.sd_device -> Link.dev 2022-07-23 20:00:44 +09:00
Luca Boccassi 9b9ddaf09d Merge pull request #24001 from yuwata/network-lifetime-fix
network: fixes for lifetime handling
2022-07-18 10:02:02 +01:00
Yu Watanabe c1dd250f18 Merge pull request #23927 from AndreKalb/feature/ipv4-link-local-start-address
network: Feature IPv4 link-local start address
2022-07-15 03:21:26 +09:00
Andre Kalb 59c272316c sd-ipv4ll/networkd: Try to select an IPv4 link-local start address 2022-07-14 14:35:42 +02:00
Yu Watanabe 5235d73960 network: fix infinite lifetime handling 2022-07-14 20:56:41 +09:00
Yu Watanabe def4741bd7 network: use sd_event_now() 2022-07-14 20:55:24 +09:00
Yu Watanabe 8f4f630731 Revert "network: configure DHCP clients after MAC address is assigned"
This reverts commit f42d41cc5f.

DHCPv6 client does not require MAC address.
DHCPv4 client will be handled in a different way in a later commit.

Partially fixes #23546.
2022-07-14 06:51:59 +09:00
Yu Watanabe 93a72170bd network: drop support for old kernels which cannot set prefix route with non-main route table
Not sure when the issue was fixed.
- kernel-3.10 on CentOS 7 has the issue,
- kernel-4.18 on CentOS 8 works fine.

Note, the workaround dropped by the commit is not incomplete:
with an old kernel which has the issue, all non-prefix routes are
configured on the specified route table, but the prefix route is
configured on the main table. That should not work for most cases,
hence, the workaround is mostly meaningless.
2022-05-21 15:09:53 +01:00
Yu Watanabe da94a69b8d network: shorten code a bit
Currently, there exist only two MTU sources, static and DHCPv4, and they
are exclusive. Hence, it is not necessary to check the existence of the
MTU option in the acquired DHCP lease. Let's unconditionally reset the
MTU. Note that, if the current and original MTU are equivalent, then
link_request_to_set_mtu() handles that gracefully.
2022-03-31 09:29:42 +09:00
Lennart Poettering ba4e0427e9 time-util: assume CLOCK_BOOTTIME always exists
Let's raise our supported baseline a bit: CLOCK_BOOTTIME started to work
with timerfd in kernel 3.15 (i.e. back in 2014), let's require support
for it now.

This will raise our baseline only modestly from 3.13 → 3.15.
2022-03-28 16:55:41 +02:00
Luca Boccassi 1bd29614ff Merge pull request #22631 from yuwata/network-redesign-request-queue
network: re-design request queue
2022-03-11 10:48:45 +00:00
Yu Watanabe 09d09207de network: re-design request queue
This makes Request object takes hash, compare, free, and process functions.

With this change, the logic in networkd-queue.c can be mostly
independent of the type of the request or the object (e.g. Address) assigned
to the request, and it becomes simpler.
2022-03-11 14:20:31 +09:00
Yu Watanabe 80d62d4f1a network: introduce request_call_netlink_async()
In most netlink handlers, we do the following,
1. decrease the message counter,
2. check the link state,
3. error handling,
4. update link state via e.g. link_check_ready().

The first two steps are mostly common, hence let's extract it.

Moreover, this is not only extracting the common logic, but provide a
strong advantage; `request_call_netlink_async()` assigns the relevant
Request object to the userdata of the netlink slot, and the request object
has full information about the message we sent. Hence, in the future,
netlink handler can print more detailed error message. E.g. when
an address is failed to configure, then currently we only show an
address is failed to configure, but with this commit, potentially we can
show which address is failed explicitly.

This does not change such error handling yet. But let's do that later.
2022-03-11 14:20:31 +09:00
Yu Watanabe ff51134c93 network: make request_process_address() and friends take Link and corresponding object
This also renames e.g. request_process_address() -> address_process_request().

Also, this drops type checks such as `assert(req->type == REQUEST_TYPE_ADDRESS)`,
as in the later commits, the function of processing request, e.g.
`address_process_request()`, will be assigned to the Request object when
it is created. And the request type will be used to distinguish and to
avoid deduplicating requests which do not have any assigned objects,
like REQUEST_TYPE_DHCP4_CLIENT. Hence, the type checks in process functions
are mostly not necessary and redundant.

This is mostly cleanups and preparation for later commits, and should
not change any behavior.
2022-03-11 14:16:41 +09:00
Yu Watanabe 3cb62efef8 dhcp: list all known DHCP options 2022-03-10 14:47:28 +09:00
Yu Watanabe 9472be2614 network: use address_set_broadcast() at one more place 2022-02-24 07:13:31 +09:00
Yu Watanabe 32f8a613c5 sd-dhcp-lease: store static routes and classless static routes in different arrays
When classless static routes option is provided, then static routes
option should not be used. Hence, let's not mix and store them in one
storage.

This introduce sd_dhcp_lease_get_static_routes() and
sd_dhcp_lease_get_classless_routes().
2022-02-02 10:02:44 +09:00
Yu Watanabe f42d41cc5f network: configure DHCP clients after MAC address is assigned
Prompted by #20090.
2022-01-31 13:10:28 +09:00
Yu Watanabe 14dd873b88 network: dhcp4: pass IPServiceType=none to dhcp client
Follow-up for b55093ce88.
2021-12-18 08:35:42 +09:00
Yu Watanabe b55093ce88 network: dhcp: make IPServiceType= accept "none" to disable tos in the outgoing packet
Fixes #9874.
2021-12-09 15:06:20 +01:00
Yu Watanabe e49bad0179 network: dhcp-pd: add 6rd support
Closes #19152.
2021-12-07 20:33:16 +09:00
Yu Watanabe 95eb38c8d0 network: route: make route_cancel_request() take Link*
As the Route object may be managed by Manager.
2021-12-06 21:30:57 +09:00
Yu Watanabe 16bc8635d5 network: address: use usec_t for handling lifetime
This drops stuct ifa_cacheinfo from Address, and store lifetime with
usec_t.

Why? Now, all requests of address configurations are once stored in
the request queue, and will be processed when it is ready. So, the
timestamp value passed to the kernel must be evaluated on configure.

This also fixes the following two issues.
- Time values in struct ifa_cacheinfo are stored in uint32_t.
  So, the validity check of the address configured by NDisc may fail on
  long running systems.
- If a system uses DHCPv6PD, when an interface may appear or be
  reconfigured later, then the lifetime value may be inappropriate.
  We need to adjust the lifetime with the current time and the timestamp
  of the lease.
2021-10-21 20:58:15 +09:00
Yu Watanabe 3b6a3bdebf network: use NetworkConfigSource/State to manage addresses and routes
This also fixes #20146.
2021-09-24 21:46:32 +09:00
Yu Watanabe e47bcb7d0b network: do not use RouteTable= in [DHCPv4] section for DHCPv6 routes
We forgot to add RouteTable= in [DHCPv6] section when we split [DHCP]
into two.
2021-09-14 17:51:19 +09:00
Yu Watanabe 471e332d50 network: dhcp4: use free_and_strdup_warn() 2021-09-14 15:21:10 +09:00
Yu Watanabe ec84bb2a2b network: dhcp4: log server address 2021-09-14 15:21:10 +09:00
Yu Watanabe 3596fb3600 network: dhcp4: return earlier on failure 2021-09-14 15:21:10 +09:00
Yu Watanabe 429dc05a72 network: move common route settings to {dhcp4,ndisc}_request_route() 2021-09-14 15:21:10 +09:00
Yu Watanabe c995fa02b1 network: dhcp4,ndisc: make addresses in Allow/DenyList= optionally take prefix length
Closes #20505.
2021-08-23 20:36:09 +09:00
Yu Watanabe 7c58ee5f8c Merge pull request #20443 from yuwata/network-conf-parser-cleanups
network: conf parser cleanups
2021-08-17 02:42:27 +09:00
Maxime de Roucy d419ef0243 network: add address label on dhcpv4
Fixes: #13967
2021-08-17 02:40:18 +09:00
Yu Watanabe 634815762d network: rebreak conf parser arguments 2021-08-16 12:54:09 +09:00
Yu Watanabe 8716018664 network: DHCP[46] -> DHCPv[46] in log messages 2021-08-10 15:02:35 +09:00
Yu Watanabe ccffa166d8 network: use request queue to configure DHCP{4,6} clients
Previously, when UUID is requested for DUID, then the clients are
configured in callback of bus methods.
But now, 'request queue' was implemented, so we can use it to wait until
the product UUID is obtained.
2021-08-10 14:55:34 +09:00
Yu Watanabe 5aebe9c898 network: downgrade log level in dhcp4_configure()
And make the callers warn about failures.
2021-08-10 14:48:18 +09:00
Zbigniew Jędrzejewski-Szmek 04499a70fb Drop the text argument from assert_not_reached()
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.

We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.

Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
2021-08-03 10:05:10 +02:00
Yu Watanabe 0ebab55f4f network: dhcp4: also support semi-static routes with Gateway=_dhcp4 when UseGateway=no or UseRoutes=no
This makes the default gateway is read from classless static routes or
router option even if UseGateway=no or UseRoutes=no, and will be used
when configuring semi-static routes such that specified with Gateway=_dhcp4.

This also changes the behavior of RoutesToDNS= or RoutesToNTP=.
Previously, the DNS or NTP servers are not in the same network, then the
routes to the servers were not configured when UseGateway=no or
UseRoutes=no. With this commit, the default gateway in classless static
routes or router option will used to connecting the servers even if
UseGateway=no or UseRoutes=no.

Fixes #20208.
2021-07-15 04:17:09 +09:00
Yu Watanabe 77976a6877 network: further unification of MUD url parsers
Follow-up for 89fa9a6b7b.
2021-07-14 17:41:00 +01:00