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.
Previously, if address_remove() or friends called with a temporary
object, the removing flag is assigned to the temporary object, and is
not set to the remembered object. Hence, e.g.
route_is_ready_to_configure() wrongly judge a required address for a
route is (still) ready, hence networkd fails to configure the route.
Fixes#28009.
If we could not remove a route, then previously the corresponding
Route object was never removed, as it was freed only when we receive
remove notification from the kernel. So, we might confused that the
route still exists and being removed, and might block reconfiguring
the route.
With this change, even if we fail to remove a route, the corresponding
Route object will be freed.
This is the one for routes of 56a995fe8e.
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 f22b586a21.
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.
The kernel uses different logics to find or distinguish IPv4 and IPv6 routes.
Let's follow the same way that the kernel uses.
See comments in the code for more details.
Also, this renames 'req' -> 'm', and makes the function unconditionally
set route type and route metric, and override type later if necessary.
Should not change any effective behavior. Just refactoring.
Except for RTAX_CC_ALGO, all RTAX_XYZ attributes take uint32_t and
the kernel's default value is zero. So, let's unify handling of the
attributes.
This should not change any effective behavior. Just refactoring.
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.
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.
Previously, we checked if the address is ready only when it is an IPv6
address. But, IPv4 address never enter tentative state, hence the check
for an IPv4 address is effectively equivalent to the one for IPv6.
So, let's unify the check. This does not change any effective behavior.