New PPPoE backend, some feedback

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.

️

stephenw10

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.

RobbieTT

@stephenw10 said in New PPPoE backend, some feedback:

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.

I've sent you some, as requested.

️