| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
This introduces a generic [Route] section parser, then embed conf
parsers for route metric into it.
|
|
|
|
|
| |
Otherwise, an existing route may be labeled as foreign even after we
reconfigure it.
|
|
|
|
|
|
|
|
|
|
| |
newly received RA
The linux kernel does not update several parameters, e.g. RTA_PREF.
Hence, when we configure routes based on a RA, we need to remove
existing conflicting routes.
Fixes #28426 and #28439.
|
|
|
|
|
|
| |
requested ones
Fixes #28853.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As networkd does not configure nexthops, neighbors, or routing policy rules
dynamically, this only changes link_drop_managed_addresses(). Previously
it also removed dynamic addresses, but with this commit, now it only
removes static addresses. Note, link_drop_managed_routes() has removed
only static routes, so this commit only changes its name.
Note. as commented in the code, the dynamic addresses will be removed
on lease expiration or stopping client, and link_drop_managed_xyz() are
called on reconfiguration or so, and at that time, all dynamic
addressing clients are stopped or restarted, so this should not
effective behavior change.
|
|
|
|
|
|
|
| |
It is not used in this commit, but will be used later.
Preparation for later commits.
This is the one for routes of 531c7246829a41dd7e51847bd4d77aa012ff478f.
|
|
|
|
|
|
|
| |
Then, Route object can live if it is detached from the owner (Manager,
Network, or Wireguard object).
This is the one for routes of ebd96906477aac2bbc6b9de0d6e9bd0f39db5581.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Then, replace route_remove_and_drop() with it.
If a route is requested, and the request is already called,
we may not received its reply and notification from the kernel, and
the corresponding Route object may not be remembered. Even in such
case, we need to remove the route, otherwise the route will come
later after the function called.
This is the version for route of f22b586a215962416bdbd692aabb89b1ac2999d0.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, a Route object is owned by a Link object corresponding to the
outgoing interface of the route, and a Route object that does not have
outgoing interface is owned by the Manager object.
However, there were several issues:
- if a route has a nexthop ID, then the corresponding nexthop may be
changed to use another interface, hence the outgoing interface of the
route may be changed.
- if a route requested with MultiPathRoute=, then the link who requests
the route is different from the outgoing interface of the configured
route. So, we need to find routes on other interfaces on reconfiguring
or so.
By this change, the limit of the number of routes per-interface is
tentatively dropped. Let's re-introduce the limit later in a nicer way.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously,
1. use the passed Route object as is when a route is requested,
2. when the route becomes ready to configure, convert the Route object
if necessary, to resolve outgoing interface name, and split multipath
routes, and save them to the associated interfaces,
3. configure the route with the passed Route object.
However, there are several inconsistencies with what kernel does:
- The kernel does not merge nor split IPv4 multipath routes. However, we
unconditionally split multipath routes to manage.
- The kernel does not set gateway or so to a route if it has nexthop ID.
Fortunately, I do not find any issues caused by the inconsistencies. But
for safety, let's manage routes in a consistent way with the kernel.
This makes,
1. when a route is requested, split IPv6 multipath routes, but keep IPv4
multipath routes as is, and queue (possibly multiple) requests for
the route.
2. when the route becomes ready to configure, resolve nexthop and interface
name, and requeue request if necessary.
3. configure the (possibly split) route.
By using the logic,
- Now we manage routes in a mostly consistent way with the kernel.
- We can drop ConvertedRoutes object.
- Hopefully the code becomes much simpler.
|
|
|
|
|
|
|
| |
This also introduce an extra argument for route_dup(), but it is
currently unused, will be used later.
No functional change, just preparation for later commits.
|
| |
|
|
|
|
| |
No functional change, preparation for later commits.
|
|
|
|
| |
No functional change, just refactoring.
|
|
|
|
|
|
|
| |
MultipathRoute with it
It is mostly equivalent to MultipathRoute. So, no functional change,
just refactoring and preparation for later commits.
|
|
|
|
|
| |
Then, scope and friends are correctly adjusted, and the behavior should
be matched when the same route is configured in .network file.
|
|\
| |
| | |
network: several cleanups for route expiration handling
|
| | |
|
| |
| |
| |
| |
| | |
Otherwise, our own expiration timer will be setup on updating a route.
See comment in link_request_route().
|
|/
|
|
| |
Let's manage nexthop (gateway) handling in networkd-route-nexthop.[ch].
|
|
|
|
|
|
|
|
| |
Then, split out route metric handling from networkd-route.c to
networkd-route-metric.c.
No functional change, just refactoring and preparation for later
commits.
|
|
|
|
|
|
|
|
|
| |
networkd-route-nexthop.c
This also split config_parse_route_boolean() into two:
for GatewayOnline= and boolean route metrics.
No functional change, just refactoring and preparation for later commits.
|
|
|
|
|
|
| |
This effectively reverts 9b88f20aba6a78baf18d89e99ff31d5ee40856b8.
We do not support MPLS routes, only IPv4 or IPv6 routes are supported.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
RFC4861 Neighbor Discovery – Sections 4.2 and 6.3.4
From section 4.2. Router Advertisement Message Format:
Cur Hop Limit 8-bit unsigned integer. The default value that
should be placed in the Hop Count field of the IP
header for outgoing IP packets. A value of zero
means unspecified (by this router).
|
|
|
|
| |
InitialAdvertisedReceiveWindow
|
|
|
|
| |
Preparation for later commits.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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")
|
|
|
|
| |
Closes #24432.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
Otherwise, if the carrir of the non-managed interface is lost, the
configs such as addresses or routes on the interface will be removed by
networkd.
|
|
|
|
| |
And move it and relevant functions to conf-parser.[ch].
|
|
|
|
| |
As the Route object may be managed by Manager.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
When a .network file is updated but its change is not so big, it is not
necessary to first drop all configs and then reassign later again.
This slightly optimize such situation. First foreignize all configs, and
then drop later when it is not requested by the updated .network file.
|
| |
|
| |
|
|
|
|
| |
This also fixes #20146.
|
|
|
|
|
| |
We forgot to add RouteTable= in [DHCPv6] section when we split [DHCP]
into two.
|
|
|
|
|
|
|
|
|
| |
This fixes the followings:
- The corresponding route or address to the gateway address must be in
the same link.
- IPv6 link local address is not necessary to be reachable.
Fixes an issue reported in https://github.com/systemd/systemd/issues/8686#issuecomment-902562324.
|
|
|
|
|
|
| |
configured by NDisc
Fixes #20244.
|
|
|
|
|
|
|
| |
networkd already has all information about routes. It is not necessary
to re-read them by using local_gateways().
This also makes manager_find_uplink() take family.
|
| |
|