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.
The history of this dates back to m0n0wall and it seems what
this tries to achieve is restarting an instance of mpd that
will dial on demand later on so the idea is to start the service
when deconfiguring it. That might seem "clear" but structurally
there's no reason to run a single shot configure during interface
disable step (likely through rc.linkup stop).
An ancinet dragon was woken from its slumber while reworking the interface
configuration code. All things considered this is more than reasonable
although we do not yet know how this condition can be reached now as opposed
to 21.7 and if the inline termination of mdp5 will not invoke any sort of
deconfiguration (ppp-linkdown) that would harm the impending start of the
service.
PR: https://forum.opnsense.org/index.php?topic=26652.0
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).
