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.
This simplifies the call a little and allows us to do better recursion
away from config-based interfaces. We could just pass the device as
the interface and it would work but then we pass it down twice and it's
not very readable.
* Configure PPP MTU only via mpd.conf making sure a derived MTU
either subtracts the header as shown in interface MTU config
or as directly set by the PPP config.
* Only set MTU on $realhwif and when it's not a device node.
* Fixup the device lookup when looking for PPPoE parents.
There seems to be an issue with qinq based MTU fixups and the fact
that the VLAN header size is not substracted, but we might just
keep it that way and fix the recursion case eventually.
like the ipv4 refactor, mapping an IP to an interface
is now done using ifconfig. For ipv6, the chances of an
interface being missed using only NDP and configuration
data are pretty high. This is largely due to most
setups not having a static IP configured, but are instead
set to track an interface with DHCP functionality enabled
under the hood by default. NDP data is also ephemeral by
nature
hopefully the last bit, this will drop parsing the config
for configured dhcp interfaces and will instead match
it on the output of ifconfig. While this would normally not
cause issues for ipv4, this is mostly done to be symmetrical
with the upcoming ipv6 leases change, where it is much more
likely for interfaces to be missed.
