When specifying `DHCPv4.SendOption=`, it is used by systemd-networkd to
set the value of that option within the DHCP request that is sent out.
This differs to setting `DHCPServer.SendOption=`, which will place all
the options together as suboptions into the vendor-specific information
(code 43) option.
This commit adds two new config options, `DHCPv4.SendVendorOption=` and
`DHCPServer.SendVendorOption=`. These both have the behaviour of the old
`DHCPServer.SendOption=` flag, and set the value of the suboption in the
vendor-specific information option.
The behaviour of `DHCPServer.SendOption=` is then changed to reflect
that of `DHCPv4.SendOption=`. It will set the value of the corresponding
option in the DHCP request.
When use UseRoutes=False so the DHCP request itself does not request
for Classless Static Routes option.
As a result, the DHCP server will only respond with a Router option.
In this case since we are using the UseRoutes=False option the gateway
that comes in via the router option does not get configured.
This patch fixes theis behaviour.
PrefixRoute= was added by e63be0847c,
but unfortunately, the meaning of PrefixRoute= is inverted; when true
IFA_F_NOPREFIXROUTE flag is added. This introduces AddPrefixRoute=
setting.
The name with plural made more sense where multiple options could be specified
in one line. After changes in the pull request, this option only accepts one
value, so from users' POV it should be singular.
(The field in the data structure remains plural, because it actually stores
multiple values.)
IPServiceType set to CS6 (network control) causes problems on some old
network setups that continue to interpret the field as IP TOS.
Make DHCP work on such networks by allowing this field to be set to
CS4 (Realtime) instead, as this maps to IPTOS_LOWDELAY.
Signed-off-by: Siddharth Chandrasekaran <csiddharth@vmware.com>
It seems that old kernels do not support prefix routes with
non-default route tables. This adds a fallback logic when adding route
fails. In that case, prefix route is created by kernel and the default
route table is used.
Some path of configuring address, route or etc., go to failed state, but
some do not. E.g., failure in address configuration which is provided by
DHCPv4 goes to failed state, but static address does not.
This is just for consistency. This should not change anything if
everything is fine.
This also voidify manager_rtnl_process_address().
When a DHCP server provides only a gateway, the networkd-dhcp4 code adds a
default route using that gateway, and sets the just-provided address as
the route's prefsrc; this was added in commit
46b0c76e2c
However, if the DHCP server has also provided classless route(s), these
are used instead of a default route using the provided gateway; the
networkd-dhcp4 code sets up the classless routes, but does not use the
just-provided dhcp address as the prefsrc of the route(s). Note that
it also doesn't set the prefsrc for static routes, though it should.
If the interface has only the dhcp-provided address, this is not usually
a problem, but if it has another address (e.g. a static address), then
traffic sent through the dhcp-provided gateway might not use the
dhcp-provided source address. If the gateway router only will route
traffic from the dhcp-provided address, then the dhcp client system's
networking through the router will not work.
Fixes: #12969
