This commit imports part of the changes from @swhite2 which will keep the legacy handling intact for the first stage of the migration. It should be backwards compatible with the previous (23.7.x) code.
Changes new in this commit which where not in the original PR:
1) dpinger_status() missed $gwitem which rendered gateways statusses down
2) Model version number set to 0.0.1 so we can use the migration later to step into 1.0.0
3) Gateways->gatewayIterator() do not yield MVC records ensuring we are still using legacy config data when being called.
Omit the dependency on wireguard-kmod as we will be targeting the kernel
module with 24.1. Some people may run into this but it's safer than
trying to rely on a package that won't be available going from 23.7 to
24.1.
Testing 3582242d0fe10 it appeared that link-local addresses were
rewritten as GUAs in the dhcpd configuration. The static map part
does this right, but all the other callers are not. Flip this
around as it was intended. The DHCPv6 page will now throw an out
of range error when it previously adjusted the explit prefix anyway.
dhcpd config with link local seems fine too, but more testing is
always good.
During bootup the gateway monitors were started before the firewall rules
were finished setting up. Under some circumstances this could lead to
incorrect data being reported by dpinger instances.
* Allow the bridge to come up without members. While the GUI made sure
to avoid empty bridges there is no reason for it and underneath if the
interface was disabled the GUI made the interface disappear from the
selection. So now allow an empty bridge (may be nice for migration)
and show disabled interfaces in the edit page. Fix all callers to not
assume the member property is always set. Can probably go away once
bridges are moved to MVC.
* Inline interface_bridge_add_member() since link_interface_to_bridge()
is the only caller. Improve the parameter passing a bit too.
* Add bridge interface return code to (_)interfaces_bridge_configure().
* Improve device resolution and a few mwexecf() replacements.
* Log the reason why a device could not be attached to bridge when one
device is not there as expected.
Now that we fail if we can't get the tunnel up improve this a bit more:
1. First order of business is adding removing/adding the device.
2. Return the device name when configuration was successful.
3. Use device name return to avoid "linking" failed devices. This
helps us to bring it up later when it is likely ready.
4. Remove the system_routing_configure() madness from device creation.
5. We may have static routes which were not adhered to previously. So now
use the same interfaces_restart_by_device() hook but omit the
interface_configure() to void unwantend recusion in that function.
This has the addded benefit of system_routing_configure() only being
called once for that interface by rc.newwanip(v6).
Formerly devices like GIF only worked on IPv4 dynamic links,
but with DS-Lite IPv6 is the only dynamic link so split the
execution on dynamic events according to what remote address
the tunnel requires. This should allow DS-Lite to work out
of the box (functional after bootup).
While here restructure link_interface_to_gif() to better fit
the caller's needs. Also feeling lucky about the stray
interfaces_bring_up() because if we check if the local address
is there we can be pretty sure the parent device is up.
PR: https://forum.opnsense.org/index.php?topic=35876.0
The terminology is confusing -- it's just a poll interval in
dpinger's alert thread like we have in gateway watcher (also
defaulting to 1 second). Since we do not want to expose
such values to the GUI without a pressing reason we better
do it this way than add more knobs that make support harder
and expectations less clear (reaction time suffers quickly when
increasing this value).
While here disable the alert thread completely in dpinger which
seems to be steered by passing the loss and delay. Also adjust
the default for the loss interval which is calculated by dpinger
as 4 times the probe interval, so the default was wrong also.
Under ideal circumstances (non-SIGKILL) the PID file and socket
are removed cleanly so they don't show up as readabe sockets in
dpinger_status(). When we kill the process the socket is there
but the open fails immediately. That only leaves a stuck process
not reacting to open, but we can deal with that by decreating the
timeout a bit more (from 3 to 1 seconds per socket). We still
want a sort of sensible timeout here that isn't too short and
assume that a system not being able to respond in time is having
other (and more criticial) issues to cope with.
Stop using the opportunistic "wan" gateway and emit a
log entry on failing to derive a viable interface name.
It's already somewhat questionable if we should use a
default gateway, but the code is what it is.
