DefaultRoute is a D-Bus property, not a valid setting name in .network
files nor resolved.conf.
Whether a link is the default route or not is configured with
DNSDefaultRoute= setting in .network files.
This introduce config_parse_routing_policy_rule(), which wraps existing
conf parsers. With this, we can drop many custom conf parsers for
[RoutingPolicyRule], and can reuse generic conf parsers in conf-parser.[ch].
Typically, conf parsers will ignore most errors during parsing strings
and return 0. Let's return 1 on success. Otherwise it is hard to reused
these function in another conf parser.
We usually do not set r = -1 when a functionality is disabled or not
supported. Even though the error code is not used, let's set a negative
errno in such case.
No functional change, just refactoring.
Follow-up for 0a4ecc54cb.
We usually configure a test rule with a unique priority. Hence, finding
rule by priority reduces the lines of output, and we can debug easily.
Also print short comments on check. That's helpful when the check is
called several times.
Otherwise, the other RoutingPolicyRule object may not have a valid
address family yet, and the existing rule may be wrongly handled as
that it is not requested by any interface, and it may be removed.
Follow-up for 727235006a.
Fixes#34068.
We can easily hit the assertions without checking the internal states of
the DHCP client before calling these functions. That's annoying.
Let's do more gracefully.
When an interface enters the failed state, even if the DHCP client is
stopped, the acquired DHCP lease is not unreferenced, as the callback
dhcp4_handler() do nothing in that case. When the failed interface is
being reconfigured after that, the DHCP client is stopped again
(though it is already stopped), and SD_DHCP_CLIENT_EVENT_STOP event is
triggered and sd_dhcp_client_send_release() is called, and the
assertion in the function is triggered.
E.g.
===
systemd-networkd[98588]: wlp59s0: DHCPv4 address 192.168.86.250/24, gateway 192.168.86.1 acquired from 192.168.86.1
systemd-networkd[98588]: wlp59s0: Could not set DHCPv4 route: Nexthop has invalid gateway. Network is unreachable
systemd-networkd[98588]: wlp59s0: Failed
systemd-networkd[98588]: wlp59s0: State changed: configuring -> failed
systemd-networkd[98588]: wlp59s0: The interface entered the failed state frequently, refusing to reconfigure it automatically.
systemd-networkd[98588]: wlp59s0: DHCPv4 client: STOPPED
systemd-networkd[98588]: wlp59s0: DHCPv4 client: State changed: bound -> stopped
systemd-networkd[98588]: Got message type=method_call sender=:1.449 destination=org.freedesktop.network1 path=/org/freedesktop/network1 interface=org.freedesktop.network1.Manager member=ReconfigureLink ...
systemd-networkd[98588]: wlp59s0: State changed: failed -> initialized
systemd-networkd[98588]: wlp59s0: found matching network '/etc/systemd/network/50-wifi.network'.
systemd-networkd[98588]: wlp59s0: Configuring with /etc/systemd/network/50-wifi.network.
systemd-networkd[98588]: wlp59s0: DHCPv4 client: STOPPED
systemd-networkd[98588]: Assertion 'sd_dhcp_client_is_running(client)' failed at src/libsystemd-network/sd-dhcp-client.c:2197, function sd_dhcp_client_send_release(). Aborting.
===
When the interface is in the failed state, link_getlink_handler_internal()
will do nothing and return zero, thus the interface will not be
reconfigured, especially when the reconfiguration is triggered in
link_enter_failed().
Follow-up for c2eb7753dd.
That indicates the interface name in 'iif' or 'oif' cannot be resolved
when 'ip rule' command is invoked. That's natural when networkd fail to
remove rule but the corresponding interface is already removed.
To make not the residual rules interfere subsequent test cases, let's
ignore the flag and actually remove unwanted rules.
Currently, these attributes are not configured by us, but there may be a
existing rule created by user manually with one of these attribute.
To correctly manage such foreign rules, let's read these attributes.
The kernel does not distinguish rules with different flags in
rule_exists(), but the flags of an existing rule cannot be updated.
Let's remove rules that have conflicting flags, and configure new rules
later with requested flags.
When we fail to remove a rule, that mostly means the rule does not exist
in the kernel anymore, e.g. already removed manually and we have not
received notification about that yet.
Let's detach the rule in that case.
Otherwise, if we fail to configure the rule, then the manager will keep
nonexistent rule forever. So, let's first copy the rule and put it on
Request, then on success generate a new copy based on the netlink
notification and store it to Manager.
This is the same as 0a0c2672db, but for
routing policy rule.
If it is already requested, the new request will be anyway silently refused by
link_queue_request_safe(), which returns 0 in such case. Let's return earlier.
There should be no functional change, just refactoring.
They are stored in Manager.rules set or Network.rules_by_section hashmap.
For safety, let's not edit them even temporarily.
No functional change, just refactoring.
Currently, only FIB_RULE_INVERT flag can be configurable, but for
simplicity and future extension, let's manage all flags.
No functional change, just refactoring.
The kernel parses FRA_SUPPRESS_PREFIXLEN as uint32_t, but internally
handled as signed integer and negative values as unset. Let's explicitly
specify the size of the variable.
No functional change, just refactoring.
Yu Watanabe