New PPPoE backend, some feedback
-
I think the connection status you see is actually an artifact of the new interface type. I can sort of replicate what you see but in fact it does connect it's just not instant. You can see what the actual state is using the new
pppcfgcommand.When you disconnect the interface in the gui it is removed entirely:
[2.8.0-BETA][admin@pfsense.fire.box]/root: pppcfg pppoe1 [2.8.0-BETA][admin@pfsense.fire.box]/root: ifconfig pppoe1 ifconfig: interface pppoe1 does not existThen as soon as you click connect the interface is created and is shown as UP but the PPP link it still connecting:
[2.8.0-BETA][admin@pfsense.fire.box]/root: pppcfg pppoe1 dev: igb1 svc: BTInfinity state: PADI sent sid: 0x0 PADI retries: 3 PADR retries: 0 sppp: phase establish authproto auto authname "bthomehub@btbroadband.com" peerproto auto [2.8.0-BETA][admin@pfsense.fire.box]/root: ifconfig pppoe1 pppoe1: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: BT options=0 inet6 fe80::201:21ff:fe01:6775%pppoe1 prefixlen 64 tentative scopeid 0x13 groups: pppoec nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>Then after some time it completes the connection:
[2.8.0-BETA][admin@pfsense.fire.box]/root: pppcfg pppoe1 dev: igb1 svc: BTInfinity state: session sid: 0x1b6d PADI retries: 4 PADR retries: 0 time: 00:00:12 sppp: phase network authproto auto authname "bthomehub@btbroadband.com" peerproto auto dns: 81.139.56.100 81.139.57.100 [2.8.0-BETA][admin@pfsense.fire.box]/root: ifconfig pppoe1 pppoe1: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: BT options=0 inet 217.45.X.X --> 172.16.13.252 netmask 0xffffffff inet6 fe80::201:21ff:fe01:6775%pppoe1 prefixlen 64 scopeid 0x13 groups: pppoec nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>The actual time taken depends how fast the server responds. For be that be almost instant or it can be several retries and 20-30s.
If you just refresh the Status page without clicking connect again it should just connect.
We saw your post on Reddit yesterday and were discussing options to make the age clearer for if_pppoe. Not sure what will happen yet.
-
@Phil2025 said in New PPPoE backend, some feedback:
Many thanks for trying the connect and disconnect, good to know its not just me, I hope they pick it up and fix it as I think it could mean if the Internet goes down for some reason, it may not come back up again by itself.
I have the same problem. I thought it was just me. Please report it on Redmine.
@RobbieTT said in New PPPoE backend, some feedback:
It may even be linked to the PPP status logs not working, as noted by others
I don't think so, this is some kind of "GUI switching between backends" problem.
As for MTU....mine is set to 1492 but I am using MSS also custom
« SpeedGuide.net TCP Analyzer Results » Tested on: 2025.04.25 05:40 IP address: 84.52.xx.xx Client OS/browser: Windows 10 (Firefox 137.0) TCP options string: 020405200103030801010402 MSS: 1312 MTU: 1352 TCP Window: 65280 (not multiple of MSS) RWIN Scaling: 8 bits (2^8=256) Unscaled RWIN : 255 Recommended RWINs: 62976, 125952, 251904, 503808, 1007616 BDP limit (200ms): 2611 kbps (261 Kilobytes/s) BDP limit (500ms): 1044 kbps (104 Kilobytes/s) MTU Discovery: OFF TTL: 54 Timestamps: OFF SACKs: ON IP ToS: 00000010 (2) Precedence: 000 (routine) Delay: 0 (normal delay) Throughput: 0 (normal throughput) Reliability: 0 (normal reliability) Cost: 1 (low cost) Check bit: 0 (correct) DSCP (DiffServ): CS0 000000 (0) - class 0, default traffic (RFC 2474).And Empty fields in WAN configuration gives me:
« SpeedGuide.net TCP Analyzer Results » Tested on: 2025.04.25 05:55 IP address: 84.52.xx.xxx Client OS/browser: Windows 10 (Firefox 137.0) TCP options string: 020405ac0103030801010402 MSS: 1452 MTU: 1492 TCP Window: 65280 (not multiple of MSS) RWIN Scaling: 8 bits (2^8=256) Unscaled RWIN : 255 Recommended RWINs: 63888, 127776, 255552, 511104, 1022208 BDP limit (200ms): 2611 kbps (261 Kilobytes/s) BDP limit (500ms): 1044 kbps (104 Kilobytes/s) MTU Discovery: OFF TTL: 54 Timestamps: OFF SACKs: ON IP ToS: 00000010 (2) Precedence: 000 (routine) Delay: 0 (normal delay) Throughput: 0 (normal throughput) Reliability: 0 (normal reliability) Cost: 1 (low cost) Check bit: 0 (correct) DSCP (DiffServ): CS0 000000 (0) - class 0, default traffic (RFC 2474).I'm pretty sure my ISP doesn't support any RFCs that would allow pushing over 1492, because the connection just fails when I set the MTU to 1500.
-
@stephenw10 said in New PPPoE backend, some feedback:
pppcfg pppoe1
Ok, that makes sense but slightly odd that GUI seems to hang for a while.
New pppcfg commands noted too:
[25.03-BETA][admin@Router-7.xxxx.me]/root: pppcfg pppoe0 dev: igc0 state: session sid: 0x1155 PADI retries: 0 PADR retries: 0 time: 14:30:28 sppp: phase network authproto auto authname "FTTP.xxxx@idnet" peerproto auto dns: 212.69.40.23 212.69.36.23 [25.03-BETA][admin@Router-7.xxxx.me]/root: ifconfig pppoe0 pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: WAN options=0 inet 93.xx.xxx.xx --> 212.xx.xx.xx netmask 0xffffffff inet6 fe80::3eec:efff:xxxx:xxxx%pppoe0 prefixlen 64 scopeid 0xf inet6 2axx:xxxx:feed:xxxx:3eec:efff:xxxx:xxxx prefixlen 64 autoconf pltime 604800 vltime 2592000 groups: pppoec nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD> [25.03-BETA][admin@Router-7.xxxx.me]/root:
️ -
Just to be clear if you actually have to click connect twice on the Status page to get connectivity that's a bug. But I don't think that's the case, it just shows UP with no IP when it initially reloads but is still connecting in the background and will connect without further interaction.
-
@stephenw10 said in New PPPoE backend, some feedback:
Just to be clear if you actually have to click connect twice on the Status page to get connectivity that's a bug. But I don't think that's the case, it just shows UP with no IP when it initially reloads but is still connecting in the background and will connect without further interaction.
I've left it 30 or 40 seconds and its not come back up, and Gateways on the Dashboard continue to show Offline and there is no connectivity, although the WAN connection has an "UP" icon, but no IP address is ever obtained and the uptime never appears. Dropping the connection and trying again it always connects in a few seconds, although still seems a tad slower than the older code, but does connect.
In 2.7.2 using the original method, PPPoE never fails and comes up in a few seconds, never takes any longer, so I can't see this being an issue with the ISP. I know it only takes a few seconds as sometimes I need to drop the connection and bring it back up again to change to better routing with my ISP, and can often do this 3 or 4 times in a row in quick succession, and it is always back up in a few seconds.
Could it be with IF_PPPoE on dropping the connection its not closing the session nicely with the ISP, so on reconnecting almost straight away the connection is refused and the connection attempt stalls? By the time we've waited a bit, seen its not working, dropped it and tried again the original session goes stale at the ISP side and so that next attempt allows the connection? Do let me know if I can supply any logs to help diagnose this.
I also have the issue of the IPv6 Gateway monitoring remaining at Unknown even though IPv6 connectivity is alive and well. The only way I can get it monitoring correctly is to edit the IPv6 Gateway, disable monitoring, then reenable and it starts monitoring okay, perhaps simply restarting of the Gateway service might achieve the same thing, but I've not tried that.
-
@stephenw10 said in New PPPoE backend, some feedback:
Just to be clear if you actually have to click connect twice on the Status page to get connectivity that's a bug. But I don't think that's the case, it just shows UP with no IP when it initially reloads but is still connecting in the background and will connect without further interaction.
Just retested and waited over 2 minutes with nothing happening, no connectivity and my PingPlotter graph (to first hop) is dead. Try again and the PingPlotter graph becomes live almost instantly with the pfSense GUI showing connected a couple of seconds later.
Still feels like a bug.
️ -
what does
pppcfgshow at that point, after the initial 'connect' in the gui? -
I've been offline for a while as went through the process again just to capture a few screenshots. It took multiple attempts to get a PPPoE connection and the WAN up and running again.
Moving from my previous 'bug' opinion to that of 'race condition'.
️ -
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.
