Make a few assumtions about complexity:
1. We can stack bridges on top of GREs stacked on top of GIFs.
2. We do not stack any virtual device on itself.
3. VIP handling in GIF/GRE is ok to coalesce if we simply create
VIPS before we start doing GIF/GRE. Bridges follow GIFs as before.
5. The reason we create unassigned devices is to assign them via GUI.
6. We do not need to run inline device creation when we assure they
are already there before we configure.
The IP alias implementation differs between GIF and GRE with
GRE being worse off since 'if' can be the IP alias and we have
no quick way of looking up the VIP. Will address later...
Anytime $gif['if'] is used the underlying function either needs to
handle _vip (CARP) case on its own or we need to shave off the CARP
designation before passing it on to not cause any mismatch on lookup.
This can only happen from the GUI when we try to inject a new
interface and we don't know the device name yet. Split this
into a device creation which reserves the name for us and move
that to configd in the next set. This also has the benefit that
the GUI page now does configuration-after-write which it is
supposed to do.
1. Use the shared $interface_details instead of reading system state
again.
2. Read and set parent device MTU before attempting to set the current
device MTU. The OS has a soft-fail on overlong MTU so we can ditch
the capping of the value.
3. Unify the test and apply code for both cases.
4. Remove follow up block that enforces problematic situations
by only trusting the system state. Integrity should already
be taken care of in GUI and configuration.
If the system fails to configure a "valid" MTU for driver reasons
we cannot catch it but then the user has bigger issues and ifconfig
exit will indicate something is wrong.
It might make sense to hide the click events in the firewall rules as well (same as the missing edit button), as we can't warrant settings being async at some point.
closes https://github.com/opnsense/core/issues/5548
This was refactored previously and all the logic should live outside
dhclient-script but it seems it's only loosely handled over there.
For now put a check back in the old way and rework this later correctly
from the system.inc point of view: we do want to register nameserver
and searchdomain in the cache files, but should not add a route if
those are not required. It would be helpful to show them in the overview
regardless (as for DNS servers) but with a hint that they are not being
used.
PR: https://forum.opnsense.org/index.php?topic=26765.0
1. IP alias was not properly selected when editing after save.
2. VIP detection was only aware of CARP address.
3. Simplify the overview by printing the interface only for CARP
to unify all 3 cases.
This easily overlaps daemons and depending on lock structure
and other serialization two daemons could easily deadlock or
play ping-pong over rc.link start/stop situations.
