It's still debatable if ifctl is a tool to record data
for interfaces and act on it or if the latter part should
be handled by more authorative (interface) code.
Inspired by: https://github.com/opnsense/core/pull/5992
For most purposes adding an IPv4 or IPv6 address already does the
UP/RUNNING thing and DHCP and PPPoE might as well so at the point
when we add the description bring it "up" explicity as well and
remove the later interface_bring_up() call.
For rtsold this is also required and IPv6 device might be different
from main device so add another "up" there and then also follow-up
with another "up" and "description" in case the main device and
IPv6 device differ.
On the overlap cases the duplicated "up" additions do not slow down
the boot.
(mod_openssl.c.2606) SSL: ssl.use-sslv2 is deprecated and will soon be removed. It is disabled by default. Many modern TLS libraries no longer support SSLv2.
(mod_openssl.c.2613) SSL: ssl.use-sslv3 is deprecated and will soon be removed. It is disabled by default. Many modern TLS libraries no longer support SSLv3.
Use the hardcoded _wlan0 append when we have the base interface already.
This only happens to "count" the number of existing clones.
We also get the opportunity to clean up get_real_interface() which was
a bit ironic calling interface_get_wireless_clone() three times and then
the other wireless code ignoring get_real_interface() in favour of
interface_get_wireless_clone().
Make the presence of <wireless/> node authoritative except
for the assignment page where we need to set this node in
the first place.
Now pivot away from a handrolled regex of devices names to
trust the output of the sysctl net.wlan.devices which is also
the prefix for our clones.
Restructure return value of legacy_interface_listget() to return
WLAN-only devices present in the system and avoid returning null
value to simplify the couple of callers (some already assumed as
much).
Assume that <wireless/> node is properly set since console.inc
always did store this. Not sure about wireless clones yet, but
will check and fix in the scope of this ticket anyway.
get_interface_list() moves to interfaces.lib.inc since it uses
most functions from there and util.inc should not want to know
about interface details in the first place. We need this later
when we work through interfaces_assign.php for device iteration
reasons.
Some call flows require this, others don't and on 22.7 we seem to miss
one that did. Instead of adding more monitor reloads in the possible
spots move the ones that are shared into the general routing reload since
the two are almost always clustered together.
Also use the $interface argument to figure out which monitors require
reloading. This will avoid quite a few spurious reloads on larger
setups.
Boot is a little special, but easy enough to ensure we don't call monitor
reload twice.
this is to adhere to the same logic as the domain overrides, since users may expect forwarded-to
servers to reply with a private address or in fact be a local controller, not setting this domain as either
private or insecure may break responses if either DNS rebinding checks (default) or DNSSEC are enabled.
ideally this should be seperate checks per entry in the future.
We are progressing steadly here, but now we need more visibility
of the sources of DNS routes to summarize servers and sources.
Also try not to deduplicate routes prematurely so that dynamic
hosts get priority over config-based ones like the override
setting actually implies as currently the last one won.
