The interfaces are created by mpd5 daemon during configuration.
We do not seem to have more than one issue here: IPv6 disable
is too soon but that is easily fixed. Device creation moves
on ok and there is no apparent error in functionality with or
without it.
While here fix the link when a $pppid is set and properly protect
the redirect url. Previously empty() was too strict and it ignored
$pppid of zero.
Also remove spurious "IP Address" help text from PPP device
configuration.
Some tunnel interface types, such as Wireguard and Tinc do support sending traffic to the interface without an intermediate host. Since we don't want to add different static checks (and would like to get rid of the ones there for legacy reasons), it's probably better to add an option here.
Add *Interfaces: Other Types: Loopback*.
- while here, also add the device name in interfaces.php and support setting an initial description on new interfaces (copy device description if available)
- check usages of lo0 and change to lo if not specific for our default loopback
We already do a more-or-less hybrid approach by starting rtsold
even if it isn't used at all. Now we also have ISPs which do
not seem to send router advertisements after successful connect
so that the reconnect misses the HUP for dhcp6c to fix the
connectivity again.
To change that remove the option and its only conditional to
behave unconditionally which has few reasons to cause regressions.
@Adschellvis and me wondered about this so I did a bit of
reseach and multiple workaround oddities exist to fix parts
of the issue. To be frank, fix the issue at the source and
do not let users otherwise configure these settings in tunnel
interfaces.
See: https://redmine.pfsense.org/issues/3280
Also see: https://redmine.pfsense.org/issues/8687
Some back and forth between explicit and implicit requires while here.
The code is helplessly glued together and no plugin facility to get
data from a function call currently exists.
It seems DHCP in 11.2 is honouring the ISPs MTU if it is sent. It
also seems there are some ISPs who send a stupid value. This fix
allows the user to ignore the ISP-supplied MTU (or not) with the
default set to ignore for compatibility with the previous behaviour.
PR: https://github.com/opnsense/core/issues/3173