[CALL FOR TESTING] Defer PPPoE dialup to after boot completes

[franco]

Hi,

Another thing we're looking at at the moment is the topic of unreliable dialling in PPPoE (although this also affects other PPP the main bulk of users is on PPPoE and it works essentially the same).

This was also discussed in the following topic although multiple problem areas exist around the current integration: https://forum.opnsense.org/index.php?topic=52824.0

The patch itself applies cleanly on top of 26.7.9 and simply moves the dailup to after boot sequence fully completed.  The idea here is to address things like avoiding early hardware quirks during interface init, providing a cleaner framework for CARP support, avoiding DHCPv6 client loops, etc.

# opnsense-patch https://github.com/opnsense/core/commit/39cca4ca785

It needs a reboot to take effect.  If it's not working simply run the patch command again.

All feedback on this is welcome.


Cheers,
Franco

[RamSense]

Hi Franco,

I tested the patch on OPNsense 26.7.9_1 (amd64) and can confirm a successful regression test after reboot.

reboot results:
- Deferred PPP startup confirmed in the system log
- PPPoE connected automatically
- IPv4 default route via PPPoE restored
- IPv4 and IPv6 HTTPS connectivity successful
- No pending PPP startup tasks
- WireGuard interface active and working.

Boot log analysis:
- PPP startup deferred: 1
- PPPoE connection successful: 1
- PPPoE disconnections: 0
- DHCPv6 restarts: 1
- DHCPv6 transmission errors: 0
- Interface startup errors: 0

The PPPoE connection was already working before applying the patch, so this confirms successful startup and no observed regressions in the tested components, rather than that I needed a fix for an existing connection failure.

Thanks for your work on OPNsense!