This reverts commit 649bcb2186.
There is a bug in the old and new behaviour, but without a proper
test case this will not fix easily. stable/26.7 doesn't use this
yet so it's sane to hotfix.
PR: https://github.com/opnsense/core/issues/10992
Was modified in 4d495ea6cc, f129c4682b et al. to a state where
the option could still be enabled but never read. The /conf bound historic
log is still filled but nothing reads it. Let's retire it for 27.1.
One other goal here is to reduce the incoming impact of a MVC/API rewrite.
Discussed with: @swhite2
This is intended to fix bootup related issues with PPPoE, e.g. where it
retriggers DHCPv6 too many times. Essentially it's the same as deferring
the newwanip scripts, but one level below since mpd5 is much more allergic
to link state changes.
This also disables the CARP handling on bootup, but does not address
the backup starting up as well as the master. Essentially this is what
reconfigure_ppp.php is meant for.
This needs more work but for now just do what we already do
while wating for the PPP device to come up: wait for the parent
as well as some drivers may take the parent down for multiple
seconds.
Ideally dialing should be deferred to after bootup which we're
already working on... 30 seconds total delay for non-functional
situation is already a lot.
PR: https://forum.opnsense.org/index.php?topic=52824.0
To ease future migrations from PPP to MVC/API and reduce the
config field "localip" misuse we want to phase out PPTP and
reduce complexity of the implementation.
While L2TP may be still around the PPTP tunneling is very likely
not used anymore. A bit of a message to everyone still using this.
Only one way to find out.
The function is called via $reload hook so adding another
hook makes no sense. This may have changed since the original
commit below and since we need to priv-sep these calls the
easiest way is to remove it. ;)
See also: https://github.com/pfsense/pfsense/commit/8e11b23f541d
As discussed internally, we want to aim for this to be the new standard,
but we will not migrate any existing setups just yet. This may need more
documentation/annotation for components (mostly legacy plugins) where this
won't work, but it's a very good start to root these out via user reports.
In e0e1401f87 we're enabling it always which also affects
assigned tunnels such as WireGuard which tend to avoid wanting
DAD so make room for leaving the flag unchanged and change it
everywhere else explicitly per type.
'newwanip' is misused sometimes and never called in static configurations.
The only consumer is the RFC2136 plugin but maybe that changes in the
future. The plugin also listens on "bootup" and "local" so simply making
a global event for use at the spots where it exists is enough.
The check was introduced in 0df1c0d so there's no technical background
to take into account. Indeed, latency_avg is probably the reading that
would least likely be 0 in this case.
Suggested by: @mbccd
This ignores the fields from the compare. There's still an issue
with the banner showing the apply message when no apply is needed
(and no todo file is added). This needs to be fixed in the UI,
but needs more glue first.
dhcpv6 depends on WAN<->LAN relationships which need a sync of
the whole interface config first.
While here enable output for diagnostic purposes when running
the script from the shell.
So we can fix the mocked $config apply in apply_pending_if_changes.php.
Ideally, toLegacy() should already do this and we just replace the whole
interface section in the script.
Rules still work, but not visible from DNAT. Migration assistant
will know that these still exist. Will be documented a bit but
low risk move in general.
As discussed internally there are no more complaints and this makes
it a bit harder to see the status at first glance, especially for the
color blind. Let's try to not tempt fate any more than we already
have on the subject.
This reverts commit f2815fabed.
This reverts commit 73e154151b.
ISC DHCP is no longer installed by default and mostly not installed
on newer installations. However, people tend to use older backups
and the server may be enabled still. The alternative would be to
add a plugin check, but I don't really see the point in dragging this
on.
PR: https://forum.opnsense.org/index.php?topic=48181.0
They are correct but it doesn't hurt to keep them in the list
to avoid noise in the config diff for now. It's easier to
spot actual issues such as "<dhcp6-ia-pd-len>0</dhcp6-ia-pd-len>"
being written to a LAN configuration.
These are not really errors. They indicate a possible issue
but should not error. An unknown hook may be normal given
that the plugin owning the hook is not installed.
We also don't consider hooks to return errors in a meaningful
way as they are meant as machinery to run a reconfiguration
which can register its own errors elsewhere in the system.
But this can give the user running manual queries a useful hint.
The original idea was to have a separate loopback queue but that
does not seem necessary. Remove the assignment again, because
otherwise the queue would be implicity late and not early as before.
Loopbacks are not "private" in the traditional sense and will be handled
by bogons in the near future to more closely align with the upstream bogon
source.
Largely these fill the same need: we run a daemon on that interface
(or a daemon that will create the software interface). Since WLAN
clones are created and reloaded earlier we are not bound to a random
place in the configure function and can eventually add a plugin hook
for this if it makes sense.
While here push the $linkup workaround down and add a comment on
why it is still needed. It would be nicer not having it but the
situation is pretty tough if the historic situation did not change.
This means we call it during device creation and reloading, which
means we can remove it from interafaces_wlan_configure() so it loses
another side effect. Just needs the reconfigure script to run the
full configuration loop then.
While here unify the function syntax to interfaces_wlan_*().
Franco Fichtner