New PPPoE backend, some feedback
-
Hmm, does it just show incrementing retries? I've seen it take 5 or 6 retries whch take 30s or so for my connection. But not longer than that.
-
@stephenw10 said in New PPPoE backend, some feedback:
what does
pppcfgshow at that point, after the initial 'connect' in the gui?It shows nothing and stops taking commands. When it finally works:
[25.03-BETA][admin@Router-7.xxxx.me]/root: pppcfg pppoe0 dev: igc0 state: session sid: 0x11b4 PADI retries: 0 PADR retries: 0 time: 00:46:38 sppp: phase network authproto auto authname "FTTP.xxxxx@idnet" peerproto auto dns: 212.69.40.23 212.69.36.23Not helpful I know.
When the GUI 'hangs' for a bit I then get the ever-helpful busy message:
Hopefully the log may be of more help.
️ -
Huh, it just returns nothing immediately? Or appears to hang waiting for something?
Returning nothing is what it does when the interface is down, before you click 'connect'. Usually!
-
As in the SSH connection stalls so nothing to access. I'm not best placed to stick the console cable in etc.
Anything useful in the system log I sent?
️ -
Nothing really jumps out. Except maybe the fact you have a 10M USB NIC connected.
Which makes me twitch but probably isn't related.During that time you disconnected and attempted to reconnect from the Interfaces Status page? And it failed connect?
-
@stephenw10 said in New PPPoE backend, some feedback:
Nothing really jumps out. Except maybe the fact you have a 10M USB NIC connected.
Which makes me twitch but probably isn't related.I may be missing something here but there is no USB NIC connected to my pfSense system. Just a DAC and an RJ45:
It's the blue lighting that makes it fast of course.
️ -
It's probably an IPMI device then. If I had to guess.
-
@stephenw10 said in New PPPoE backend, some feedback:
It's probably an IPMI device then. If I had to guess.
It does have an Aspeed IPMI and the BMC has a dedicated LAN port (not currently in use).
️ -
@stephenw10 said in New PPPoE backend, some feedback:
During that time you disconnected and attempted to reconnect from the Interfaces Status page? And it failed connect?
After the first reconnection attempt it just went around in that loop so the 'hotplug' events are all self-generated. Quite a few services and packages were also trying to start before it was possible to do so with the pppoe state.
Other oddities include waiting on Tailscale which, whilst installed, is actually disabled and services not finding ports available, failing, restarting, then all packages restarting etc. This also included unbound, pfBlocker, Avahi, vnstatd, php, IPSec tunnels and OpenVPN (also not in use) and the kernel not happy about 'Media change is not supported' etc. I'm presuming the startup sequence has changed little but perhaps with the pppoe change it's just tying itself in knots?
It's all a bit random and messy but nothing that looks like an obvious cause. It still feels like a race condition though. Doing either a cold boot or a reboot has (so far) had no such issues. Just taking the pope interface down and back up again triggers it all.
Maybe the fix applied for the previous pppoe race condition for the older mpd5 pppoe backend has become undone?
️ -
Your logs don't include the boot sequence so it only shown as something vnstat is monitoring:
vnstatd 12727 Monitoring (13): ue0 (10 Mbit)The logs also show that some of the NICs actually lost link like:
Apr 25 13:03:38 kernel ice0.1003: link state changed to DOWN Apr 25 13:03:38 kernel ice0: link state changed to DOWNWas that you unplugging/rebooting something?
-
@stephenw10 said in New PPPoE backend, some feedback:
Was that you unplugging/rebooting something?
No, not touching anything, it's all self generated issues as it ties itself in knots for either a short period or a very long one.
For now, a full reboot is the most reliable method of connecting PPPoE (connecting on first attempt) and often it is much faster than taking the interface down and up again, as I would normally do.
Outside of this weird bug or race condition the new PPPoE backend is very impressive. The CPU even runs a bit cooler when ticking over with background traffic at night.
I've little time for proper testing (my wife is ill) but if there is something specific you would like me to run or capture then I will do my best to do so, when I need the distraction. Exact commands that I can paste in with little thought would be ideal.
️ -
Hmm, OK.
If you can try to grab a packet capture on the parent NIC when it's failing to connect. Just to make sure it really is trying or if something low level is preventing it.
