New PPPoE backend, some feedback
-
I have switched to a new backend via Advanced settings.
. 2025-04-04 18:19:16.432734+03:00 php-fpm /rc.carpbackup: Error configuring PPPoE interface pppoe0I see nothing in the PPP log, only these messages in the System log, twice after reboot. This is definitely caused by the parent interface, which is a VIP on the LAGG.
It looks like I can no longer select a LAGG as the parent interface for PPPoE?
Temporarily, I have deleted the LAGG and configured the physical interface instead.Also, there is some issue with password autofill on the WAN configuration page. With the old backend, everything is autofilled:
and on the new
the password fields are never autofilled. When I try to use Firefox’s autofill by clicking on the field, it gets filled and I can save the settings, but then I get:
2025-04-04 18:57:01.141622+03:00 kernel - if_pppoe: pppoe0: chap failureI checked the browser’s saved password and didn’t find anything useful. It looks like it just saved some *****-like symbols instead of the actual password. So I entered the password manually, and it worked.
So in conclusion: LAGG is not working as a parent interface, and the password must be re-entered manually once when configuring WAN.
My question is: Will LAGG support be re-enabled as a parent interface for PPPoE in the future?
Password thing looks like just some browser glitch.
-
Some more feedback about the new PPPoE client.
As confirmed in reddit, traffic shaping doesn't work with the new PPPoE client, seems an odd oversight but being looked into.
I also see no logging either in the PPP system logs when the new if_PPPoE is in use.
Overall PPPoE now seems extremely slow to connect and show the gateway details, both with the new and original clients. The if_PPPoE doesn't always bring up the IPv6 gateway, if it does, no monitoring address gets set so its marked as offline. Switching back to the old client, it always gets a monitoring address but is still slow compared to how it works with 2.7.2.
I started having a look at the scripts at /usr/local/sbin/ppp-linkup and ppp-linkdown to see what has changed, and I'm not convinced the changes are correct.
Taking ppp-linkdown and just one IF statement:
In 2.7.2 it is:
if [ "${PROTOCOL}" == "inet" && -s "/tmp/${IF}_defaultgw" ]; thenIn 2.8.0 BETA the same line is
if [ "${PROTOCOL}" = "inet" ] && [ -s "/tmp/${IF}_defaultgw" ]; thenNotice == changed to a single equal. I don't program much in PHP, but the correct syntax as far as I'm aware should be == to make a comparison, the single equal is used to assign variables. This change in syntax is repeated in this file and link up, I've not looked at any others.
So wondering why it has been changed and if it is really correct?
-
Just a quick reply to my own post. After a bit of research (Googling) it seems when using 'Bash' that a single '=' is fine in comparisons, just other languages it usually isn't. So I guess someone has been doing a tidying up.
-
@Phil2025
GPT says°Summary:
In PHP 8+, = is used for assignment, == for loose comparison, and === for strict comparison (checks both value and type).When using == in if statements, be aware that comparing a number to a non-numeric string (e.g. 0 == "abc") returns false. PHP no longer tries to convert such strings to numbers automatically, which makes comparisons more predictable.
Also, writing if ($x = 5) assigns the value 5 to $x and always evaluates as true, which can be a common mistake when the intention was to compare (==). It's safer to use === for clear and strict comparisons.°(GPT)
-
@w0w yes that is true for PHP and why I queried it as it looked wrong, however I think it is Bash script rather than PHP, and in Bash a single equals for a comparison is okay. Hopefully a Dev can confirm.
-
@Phil2025
I am not sure, still waiting for the LAGG issue answer too, don't want to rise it since the new build is expected "soon, very soon",.but I hope they read this topic also, even if not commenting. -
@w0w I can't give you thumbs up to say I agree just yet as its a new account. I hope they aren't releasing this soon as PPPoE has regressed, its slower to connect (old one and new), and the new If_PPPoE doesn't support everything as you and I have found. If someone has traffic shaping enabled and the new if_PPPoe becomes the default, then people are going to find themselves unable to connect back to their ISP after upgrading, until all traffic shaping rules are removed. No mention of this caveat in the BETA release notes. Also I want traffic shaping to avoid buffer bloat and to give VoIP priority.
Then you have spotted issues with LAGG. I also have a problem where the new if_PPPoE will fail to bring up the IPv6 gateway correctly (fine on the old one), and we can't provide any logs for troubleshooting as nothing is getting logged.
-
I can't replicate the LAGG issue. It works fine for me in a test setup:
[2.8.0-BETA][admin@m370.stevew.lan]/root: pppcfg pppoe0 dev: lagg0 state: session sid: 0x2 PADI retries: 1 PADR retries: 0 time: 00:03:50 sppp: phase network authproto auto authname "Test" peerproto auto dns: 10.0.5.128What error exactly are you seeing?
-
The ppp linkup scripts are neither php or bash, they use the FreeBSD standard shell sh.
Yes, it looks like those were corrected from the earlier version. And I'll certainly defer to Brad there!
-
@stephenw10 said in New PPPoE backend, some feedback:
the ppp linkup scripts are neither php or bash, they use the FreeBSD standard shell sh.Oh, well, missed that…
@stephenw10 said in New PPPoE backend, some feedback:
can't replicate the LAGG issue. It works fine for me in a test setupHmm... Last time I tried it, the LAGG interface was just missing from the list.
Now that you said you can't replicate it, I went to the GUI and tried to recreate the LAGG. I re-created it, pressed Save, the page loaded and then stopped — so I pressed Save again, just to get a "problem loading page" in FF, and found that the firewall had just crashed.amd64 15.0-CURRENT FreeBSD 15.0-CURRENT #0 plus-RELENG_25_03-n256448-5d69d8519d49: Tue Feb 4 00:57:41 UTC 2025 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/obj/amd64/DugkeSvO/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/sources/FreeB Crash report details: No PHP errors found. Filename: /var/crash/info.0 Dump header from device: /dev/ada0p3 Architecture: amd64 Architecture Version: 4 Dump Length: 456704 Blocksize: 512 Compression: none Dumptime: 2025-04-07 17:43:48 +0300 Hostname: c_primary.ccccc Magic: FreeBSD Text Dump Version String: FreeBSD 15.0-CURRENT #0 plus-RELENG_25_03-n256483-08e0bace8aeb: Thu Mar 6 02:18:06 UTC 2025 root@freebsd:/var/jenkins/workspace/pfSense-Plus-snapshots-25_03-main/obj/amd64/lpwib8GT/var/ Panic String: page fault Dump Parity: 3854542699 Bounds: 0 Dump Status: good db:0:kdb.enter.default> run pfs db:1:pfs> bt Tracing pid 12 tid 100069 td 0xfffff80002c1f740 kdb_enter() at kdb_enter+0x33/frame 0xfffffe00d71678e0 panic() at panic+0x43/frame 0xfffffe00d7167940 trap_fatal() at trap_fatal+0x40b/frame 0xfffffe00d71679a0 trap_pfault() at trap_pfault+0x46/frame 0xfffffe00d71679f0 calltrap() at calltrap+0x8/frame 0xfffffe00d71679f0 --- trap 0xc, rip = 0xffffffff80e50987, rsp = 0xfffffe00d7167ac8, rbp = 0xfffffe00d7167b50 --- lagg_port_output() at lagg_port_output+0x7/frame 0xfffffe00d7167b50 pppoe_start() at pppoe_start+0xc2/frame 0xfffffe00d7167bc0 sppp_output() at sppp_output+0x290/frame 0xfffffe00d7167c10 ip6_forward() at ip6_forward+0x736/frame 0xfffffe00d7167d10 ip6_input() at ip6_input+0xa5c/frame 0xfffffe00d7167df0 swi_net() at swi_net+0x128/frame 0xfffffe00d7167e60 ithread_loop() at ithread_loop+0x239/frame 0xfffffe00d7167ef0 fork_exit() at fork_exit+0x7b/frame 0xfffffe00d7167f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00d7167f30 --- trap 0x214cd131, rip = 0xc0c148f88948c701, rsp = 0xf18948c8314819c0, rbp = 0x4cf12148d90948c1 --- db:1:pfs> show registers cs 0x20 ds 0x3b es 0x3b fs 0x13 gs 0x1b ss 0x28 rax 0x12 rcx 0x98ba0a0988e4b5aa rdx 0xfffffe00d7167400 rbx 0x100 rsp 0xfffffe00d71677b8 rbp 0xfffffe00d71678e0 rsi 0xfffffe00d7167670 rdi 0xffffffff82741bf8 vt_conswindow+0x10 r8 0x30 r9 0x30 r10 0 r11 0 r12 0 r13 0 r14 0xffffffff81468998 r15 0xfffff80002c1f740 rip 0xffffffff80d4e3d3 kdb_enter+0x33 rflags 0x86 kdb_enter+0x33: movq $0,0x1d70132(%rip) db:1:pfs> show pcpu cpuid = 4 dynamic pcpu = 0xfffffe009b59c540 curthread = 0xfffff80002c1f740: pid 12 tid 100069 critnest 1 "swi1: netisr 3" curpcb = 0xfffff80002c1fc60 fpcurthread = none idlethread = 0xfffff800025ef740: tid 100007 "idle: cpu4" self = 0xffffffff83a14000 curpmap = 0xffffffff82a62770 tssp = 0xffffffff83a14384 rsp0 = 0xfffffe00d7168000 kcr3 = 0x80000000c57ed002 ucr3 = 0xffffffffffffffff scr3 = 0x2ed483ae3 gs32p = 0xffffffff83a14404 ldt = 0xffffffff83a14444 tss = 0xffffffff83a14434 curvnet = 0xfffff80001237040 db:1:pfs> run lockinfo db:2:lockinfo> show locks No such command; use "help" to list available commands db:2:lockinfo> show alllocks No such command; use "help" to list available commands db:2:lockinfo> show lockedvnods Locked vnodes db:1:pfs> acttraceLooks like I’m lucky… again. This must be related to PPPoE being enabled on one of the interfaces I tried to assign to the LAGG. So I guess it's OK :-)
Anyway... Now, after trial and error, I managed to create the LAGG again, went to Interfaces → PPPs to select my LAGG as parent interface for PPPoE, and — there are no LAGG interfaces at all. It only shows VIPs, VLANs, and no LAGGs.
I really don't know what exactly I am “doing wrong” this time. -
Hmm, so that crash was due to having pppoe already running on an interface that you added to a new lagg?
Still it should not be possible.
There does seem to be a 'quirk' here. As you say laggs are excluded from the pppoe parent interfaces list but if you create the lagg then assign it then change the IPv4 type to pppoe it will allow it.
But that doesn't seem to be a recent regression.
-
@Phil2025 said in New PPPoE backend, some feedback:
I hope they aren't releasing this soon as PPPoE has regressed, its slower to connect (old one and new), and the new If_PPPoE doesn't support everything as you and I have found. If someone has traffic shaping enabled and the new if_PPPoe becomes the default, then people are going to find themselves unable to connect back to their ISP after upgrading, until all traffic shaping rules are removed. No mention of this caveat in the BETA release notes. Also I want traffic shaping to avoid buffer bloat and to give VoIP priority.
I’m sure they’ll fix most of the bugs before the release, or at least MPD will work the same way as before. It’s absolutely fine to have something broken at the beta stage, especially when such a major change is taking place.
@stephenw10 said in New PPPoE backend, some feedback:
Hmm, so that crash was due to having pppoe already running on an interface that you added to a new lagg?
I just tested it again. Yes, it is possible to try to create a LAGG even if PPPoE is enabled on one of the interfaces that the LAGG consists of.
@stephenw10 said in New PPPoE backend, some feedback:
here does seem to be a 'quirk' here. As you say laggs are excluded from the pppoe parent interfaces list but if you create the lagg then assign it then change the IPv4 type to pppoe it will allow it.
Ok just did it. I've just forgot about this 'quirk'. It works, yes.
Now I remembered how the original configuration was set up — the one that works with the old backend using MPD, but doesn’t work with the new one.
I should probably mention that this is that same “unsupported” CARP + PPPoE configuration that was once posted by someone on this forum. The idea is that it automatically brings up PPPoE on whichever firewall is currently the CARP master.
I created a LAGG consisting of two ports from the same NIC — ixl0 and ixl1. Then I assigned it to an interface named WAN_ISP, gave it a static IP address of 10.0.110.2, and created a corresponding VIP 10.0.110.1. On the second firewall, the setup is roughly the same, except the WAN_ISP interface address is 10.0.110.3, accordingly.This setup “somehow works” with the MPD-based configuration and not working with new pppoe stack, just getting
/interfaces_ppps_edit.php: Error configuring PPPoE interface pppoe0Maybe this setup should just be scrapped and forgotten altogether, as I’m not even sure it works properly or as intended.
Still, the question remains open — why doesn’t it work with the virtual IP assigned to the LAGG, but does work when using the LAGG directly?
-
Ah, yes PPP connections are not supported in HA setups indeed. But as you say if can be made to work (ish). What is the parent for the PPPoE there then? The CARP VIP? I don't think that's possible.
-
@stephenw10 said in New PPPoE backend, some feedback:
What is the parent for the PPPoE there then? The CARP VIP? I don't think that's possible.
Yes, it's a CARP VIP. I think I'll just get rid of it.
-
I can't remember or find that thread, but I think someone already asked about this...
Where exactly does the new PPPoE backend write the connection log?Status/System Logs/PPP contains only old mpd records.
-
Hmm, well it looks like you can (or could) actually set a CARP VIP as a PPPoE parent. Which seems illogical but....
And I assume you can't with if_pppoe because that's not a physical interface....
There isn't anything like the same logging that mpd gives. Yet. I would run a pcap on the parent NIC and see whats actually happening. I would think it has to send from the CARP MAC since it clearly doesn't us the actual VIP IP.
-
@stephenw10 said in New PPPoE backend, some feedback:
There isn't anything like the same logging that mpd gives. Yet. I would run a pcap on the parent NIC and see whats actually happening. I would think it has to send from the CARP MAC since it clearly doesn't us the actual VIP IP.
Are you talking about the mpd backend or the new one? On the new one, when selecting the CARP VIP, the pcap on the parent interface naturally shows nothing — the new backend simply can't configure itself properly and doesn't start at all.
Interesting. I switched back to mpd, leaving the settings with the VIP that were configured for the new backend — and now PPPoE doesn't want to work even with mpd. Something is definitely wrong with the configuration conversion between the two backends.
In the log, it also looks like it's connecting through the wrong interface:
2025-04-08 18:55:45.407053+03:00 ppp 56619 [wan] Bundle: Interface ng0 created 2025-04-08 18:55:45.406382+03:00 ppp 56619 web: web is not running 2025-04-08 18:55:44.495307+03:00 ppp 36089 process 36089 terminated 2025-04-08 18:55:44.446476+03:00 ppp 36089 [wan] Bundle: Shutdown 2025-04-08 18:55:44.403502+03:00 ppp 56619 waiting for process 36089 to die... 2025-04-08 18:55:43.401537+03:00 ppp 56619 waiting for process 36089 to die... 2025-04-08 18:55:42.400289+03:00 ppp 36089 [wan] IPV6CP: Close event 2025-04-08 18:55:42.400259+03:00 ppp 36089 [wan] IPCP: Close event 2025-04-08 18:55:42.400219+03:00 ppp 36089 [wan] IFACE: Close event 2025-04-08 18:55:42.400117+03:00 ppp 36089 caught fatal signal TERM 2025-04-08 18:55:42.399979+03:00 ppp 56619 waiting for process 36089 to die... 2025-04-08 18:55:42.399687+03:00 ppp 56619 process 56619 started, version 5.9 2025-04-08 18:55:42.399135+03:00 ppp 56619 Multi-link PPP daemon for FreeBSD 2025-04-08 18:54:43.826132+03:00 ppp 36089 [wan] Bundle: Interface ng0 createdbut nothing on LAGG
Ok next step...
I booted into the previous snapshot from February, launched PPPoE and pcap there —
Here’s an example of one of the packets:
b4:96:91:c9:77:84 is just active ethernet card ixl0 MAC form LAGG (FAILOVER) I have used for CARP VIP.
-
Hmm, well I can certainly see why that might fail. Setting it on a VIP really makes no sense for a L2 protocol. It seems like it worked 'by accident'. I'm not sure that will ever work with if_pppoe. I'll see if Kristof has any other opinion...
-
@stephenw10 I don't see how setting a carp IP on a PPPoE interface would make sense, no.
It doesn't make sense on the underlying Ethernet device (because it's not expected to have an address assigned at all), and also doesn't make sense on the PPPoE device itself, because there's no way to do the ARP dance that makes carp work.
-
@kprovost said in New PPPoE backend, some feedback:
It doesn't make sense on the underlying Ethernet device (because it's not expected to have an address assigned at all), and also doesn't make sense on the PPPoE device itself, because there's no way to do the ARP dance that makes carp work.
The whole point is to use the status of the parent interface to bring up the PPPoE interface. To determine the status of the parent (underlying) interface, the CARP VIP on the parent interface is exactly what's needed — to identify which node is the master and where to bring up PPPoE. Honestly, I have no idea why it even worked before. But if it's not supposed to work and never will, then of course I won't insist on this approach :)
Ideally, there would simply be a feature to bring up the PPPoE WAN session only if the firewall is the MASTER.
I doubt I'm the only one whose ISP doesn't appreciate users trying to initiate more than one PPPoE session.
