In theory we should be able to move the host routes for 6rd and 6to4
easily without repercussion, unless some part of the system tries to
reload the interface without calling system_routing_configure().
Try to avoid touching default routes in dhclient-script which we
already partially do now. PPPoE linkdown certainly doesn't need
to handle the file as well to remove the default route then.
Some call flows require this, others don't and on 22.7 we seem to miss
one that did. Instead of adding more monitor reloads in the possible
spots move the ones that are shared into the general routing reload since
the two are almost always clustered together.
Also use the $interface argument to figure out which monitors require
reloading. This will avoid quite a few spurious reloads on larger
setups.
Boot is a little special, but easy enough to ensure we don't call monitor
reload twice.
We are progressing steadly here, but now we need more visibility
of the sources of DNS routes to summarize servers and sources.
Also try not to deduplicate routes prematurely so that dynamic
hosts get priority over config-based ones like the override
setting actually implies as currently the last one won.
Later we want ifctl to add the scope to the link-local gateway
by default which will remove a more code, but for now we are
bound to undo the internal magic.
Interface name stops with first ":" or last "_". For the exclude
check use the correct array index, not the array itself.
Already noticed that "ipsec" devices were throwing wrenches into
the engine here so try to match exactly on the pseudo-interface
names given by the GUI.
Number of people noted spurious restarts of Unbound and this seems
to be the cause. However, the real cause of hammering rc.newwanip
is in 797c18641944 and to avoid other side effects like the GIF/GRE
stuff we should consider reverting part of it.
Ok so this might have been an issue in the past WRT DHCP client
and default route hanling which is now done another way but maybe
it shouldn't have. For now just see how this works in practice
and then decide later if more needs to be done or not.
We do want to eventually lean on exclusive ifctl use in order to
be able to improve logic in ifctl or make adjustments really easy in
the future without missing a spot (e.g. adding scope to link-local
routers).
We can set gateway to null as it is ignored when setting host
route. Also adhere to logic for interface selection in both
DNS modes, but only exclude from configuration list for dynamic
ones.
For the time being we don't need static/dymanic annotation
as the system doesn't care by design and we don't filter it
anywhere else. Might be something for the status page, but
that's a larger change to level expectations vs. dyamic
connectivity properties.
A couple of style issues here and there as well.
Looking for things that could go wrong with root.key in Unbound
this could be one of those. Still, at this point we may not have
received DNS servers from the ISP since these are registered much
later (10-newwanip).
Great opportunity to ditch prefer_ipv4_or_ipv6() since we need it
for resolving which we set up alongside and in the right spot.
Routes only get added in system_resolvconf_generate() now where
the DNS override is properly checked. The nameservers are added
through the new script for convenience and removed from there as
well. As a bonus we still scrub the routes from the nameserver
file removal to avoid creating "state" about what was done elsewhere.
This is still subject to a lot of funky races for overlapping host
routes either by ISP, manual DNS, gateway monitors or static routes.
The far gateway flag has some benefits for configuration runs
and validation purposes on the GUI but in the end after lots
of reworks we are able to reliably get a network from the interface
to put the default route on so that we can detect if we are in
need of a far gateway or not. This is required for automatic
gateways on DHCP that hand out these situations while the
gateway code should not be in charge of flipping on the fargw
bit as it does pertain to runtime interface configuration.
Leave the fargw configuration flag in place for now to let people
test this, maybe backport it earlier and look at fargw more
closely in the remaining use case(s).
o Merge defaults and requirements.
o Get rid of get_default_sysctl_value().
o Manually set 'type' for e.g. boot enviroment tunables.
o Cache sysctl map once per boot.
o Edit system defaults for easier override.
While sysctls might change when (un)loading kernel modules the
risk of missing something vital is not given. We could always
flush the cache file in that case later.
It changes with each build since it has a rebuild date but most
of the time it is not being reinstalled. Besides this helps testing
and is relatively portable since we don't rely on the actual content.
