New PPPoE backend, some feedback

RobbieTT

@Phil2025

I have 1508 MTU set on the interface carrying the PPPoE encapsulation (listed as ONT in my examples above).

The un-molested WAN connection inside this encapsulated and slightly larger MTU pipe is set at the standard 1500 MTU (albeit note @stephenw10's comments above).

I don't think the ISP or Openreach can negotiate a 1508 MTU if you have a smaller one set. Indeed, there are many users out there with either no appreciation for baby jumbo frames or have inflexible hardware that does not allow for an MTU above 1500 to be set.

The BT SINs make no mention of being able to negotiate a higher MTU than requested; the exact opposite is stated though, with connectivity warnings. From memory the BT SINs give a maximum MTU of 1530 (previously 1520) on the Openreach network.

I'm not sure what overheads can be tweaked or removed on my PPPoE connection to get additional throughput though - can you expand on these for me please?

️

stephenw10

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 pppcfg command.

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 exist

Then 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.

w0w

@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
da67a5ef-ac36-420d-996e-1f92444e2eb7-{0E1ED290-FD16-4525-ADCE-89C980D30C5C}.png

« 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.

RobbieTT

@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:

️

stephenw10

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.

Phil2025

@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.

RobbieTT

@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.

️

stephenw10

what does pppcfg show at that point, after the initial 'connect' in the gui?

RobbieTT

@stephenw10

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'.

️

stephenw10

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.

RobbieTT

@stephenw10 said in New PPPoE backend, some feedback:

what does pppcfg show 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.23

Not helpful I know.

When the GUI 'hangs' for a bit I then get the ever-helpful busy message:

2025-04-25 at 14.37.31-GUI droped.png

Hopefully the log may be of more help.

️

stephenw10

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!

RobbieTT

@stephenw10

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?

️

stephenw10

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?

RobbieTT

@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.

️

stephenw10

It's probably an IPMI device then. If I had to guess.

RobbieTT

@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).

️

RobbieTT

@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?

️

stephenw10

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 DOWN

Was that you unplugging/rebooting something?

RobbieTT

@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.

️