Use the placeholder (hint) as documentation and remove the help text
message which duplicates the same (plus the potential of being broken
in a translation).
We need far gateway routes (interface routes) for each gateway not
directly attached to the network or else the monitoring for it fails
which prevents a default route from being added which would fix it.
Since system_default_route() is private nowadays allow to pass down
the gateway struct which simplifies/speeds up the process.
We also pull in "configctl -- interface routes list -n json" data when
doing a reconfiguration to check if the interface route needs to be
touched and we can also use this check for default route and perhaps even
static routes later on.
Now we would rather want to fix the missing links correctly than
to drag this out. The biggest issue here is that we starts everything
with detached mode wich means IPv4 and IPv6 will both try to set default
routes while this will also try to set default routes which is not good.
Noticed this while testing interface routes rework as the log messages
were overlapping from different scripts doing the same.
e5006e9e4 was already fixing the routing for STF so I guess GIF and
GRE are next... Looking at rc.newwanip bridges probably have the same
issue.
It seems it's possible for whitespace to exist between the double quotes
and iaid_duid identifier. We also make sure that we're correctly
able to identify the ending bracket of a single iaaddr or iaprefix
segment.
This should considerably lower CPU usage as reported a few times.
We do need to bring in pcntl PHP module in order to get that done
easily in the script.
PR: https://forum.opnsense.org/index.php?topic=35219.0
This is useful in cases where "empty" has special meaning, but is allowed
to occur multiple times, while any set value still has to adhere
to the unique constraint.
Set resulting MTU on the assigned PPP device as well as doing the
right thing for setautosrc translating the device name and doing it
post-load when netgraph is loaded.
Don't do both of these things for MLPPP as we would end up with
inconsistencies of multiple devices trying to set (possibly differing)
values.
This is possible now since we no longer set the MTU on the PPP device,
wich is not created before IPv4 handling. We may have to add the MTU
to the PPPoE device as well, but from the looks of it this does not
matter for one reason or another.
For a VLAN on top of HW this doesn't seem required (although it makes sense)
the VLAN on top of VLAN actually needs this so add it for both.
It should be said that this is simply trying to fix setting oversize MTU
values and therefore now backs off when the parent MTU fits the requirement.
Still try to set any bad MTU value configured by the user.
