For IPv4 this should be backwards compatible with the previous code, since the netmask isn't really used to determine if the other end is reachable (it seems so at least), for ipv6 some consumers a valid netmask
seems to be required in order to function properly (frr). Since ipv6 doesn't seem to support setting a netmask in combination with a destination address and the other end apparantly doesn't really care, we just set an address with a mask in case it's an ipv6 tunnel.
for https://github.com/opnsense/core/issues/4700
It can be snatched from any mirror if given which is very
bad when FreeBSD repo is enabled. A simple pkg-install
will pull in pkg and break the system.
We have to see how this holds up in practice. Reinstall was considered
as well for further protection but that might be even trickier depending
on what locking and version tricks the user did to their install to
retain a particular (working) state.
While testing pkg was snatched from FreeBSD mirror, which isn't
advisable (nevermind that FreeBSD mirror was enabled in the first
place).
Do the same for the release type shift to avoid pivoting towards
third party repos for any reason whatsoever.
The issue is that some users assume there is manual need for
file changes as prompted by FreeBSD package manager and its
ports, but that is generally not the case when using OPNsense.
For core functionality and plugins the GUI takes care of all
these manual maintenence steps.
This way the build can do all sorts of funny things and we will end up
with a consistent config.xml after boot. For people restoring other
config.xml that is not the case but in this scenario the user is likely
aware of what he or she is doing.
xml-rpc isn't used very often these days, it proably doesn't make sense to try to upstream this change since the library doesn't seem to be very active anymore.
When values are of non string type, it makes sense to trim() for safety, for strings leading spaces can have a meaning.
While here the API now tells the page what it should do.
We always consume updates first and then tell the user
it is all well or that an upgrade is available.
Errors are shown as well although when the API has a
fatal issue we don't want to try to force a reaction
and instead just log to console.
The major upgrade needs another fold to be made even
quicker than before but for today that is enough.
