New PPPoE backend, some feedback

w0w

@patient0
This may be a manifestation of the same bug: https://forum.netgate.com/topic/197119/dns-resolver-exiting-when-loading-pfblocker-25-03-b-20250409-2208. Some ISPs send RA packets too aggressively, and due to a bug, pfSense starts endlessly restarting related services and daemons. On certain hardware, it's even possible that PHP hangs as a result.

stephenw10

Yup I'd bet it's that ^. Should be fixed in the next beta build.

RobbieTT

@w0w said in New PPPoE backend, some feedback:

@patient0
This may be a manifestation of the same bug: Some ISPs send RA packets too aggressively...

Thankfully my ISP is very mild with the RAs (and complies with the standards), so it is very rare for the process to be triggered by an RA and is almost exclusively an RS from pfSense kicking it all off.

The dns-resolver loosing its mind when pfBlocker does its thing would probably explain why the fqdn gets tossed.

Whilst it doesn't solve everything the 171.diff experimental patch has really calmed things down on boot & interface status change. Looking forward to all this being collected in a new beta. This is all looking positive.

️

w0w

@RobbieTT said in New PPPoE backend, some feedback:

171.diff

Where can I get it?

stephenw10

Here's the file to test. This is not the final fix that will be in the build though.
171.diff

w0w

@stephenw10
Oh yes, I tested an earlier version too, but this one at least works with the latest snapshot.
It looks promising.

RobbieTT

@stephenw10

I'm not sure if my buffer bloat on 23.05 / PPPoE is truly related to all this so I have opened a different thread here.

️

chrcoluk

@w0w said in New PPPoE backend, some feedback:

@patient0
This may be a manifestation of the same bug: https://forum.netgate.com/topic/197119/dns-resolver-exiting-when-loading-pfblocker-25-03-b-20250409-2208. Some ISPs send RA packets too aggressively, and due to a bug, pfSense starts endlessly restarting related services and daemons. On certain hardware, it's even possible that PHP hangs as a result.

I think the service restarting code needs a looking at, I will confess on my personal install of pfSense, I have disabled a lot of it, as I found its way too aggressive at mass restarting services.

As an example is no need to restart the ups daemon if a VPN cycles.

I would either restrict the services that restart, instead of a blanket restart all services, or make it optional tick box in advanced settings. Most people are probably only using services LAN side anyway so restarting them because of a change of WAN conditions seems excessive.

w0w

@chrcoluk
You may be right. Everything eventually needs to be reevaluated. We're dealing with a complex software construct that tries to account for all the situations that may arise from thousands of different user configurations. And as far as I remember, the whole reconfiguration/restart behavior has been around for a long time, even though some services might no longer need it.
As the saying goes... if you want something done — submit a feature request, or maybe… a bugfix.

chrcoluk

@w0w Thats the plan, but I need to be sure I am not submitting something that only works for me and breaks for others, it needs care taken on this issue.

louis2

I did test the new PPPoE this morning trying multiple settings on a simple fiber connection.

It did work for IPV4 however NOT for IPV6. So after a short test trying multiple settings I switched back to the old PPOE.

For info:

internet is arriving via vlan6
PPOE is listening to that vlan

The settings for the old PPOE and also supposed settings for the new version

IPV4: PPPoE
IPV6: DHCP6
MTU: (default)
MSS: 1492
Use IPV4: YES
Request only IPv6 prefix: YES

That did not work for IPV6 so I did try SLAAC and using the default MSS etc did not work.

So I switched back after this short test.

stephenw10

If you can test again try enabling DHCP6 Debug in System > Advanced > Networking.

I have that setup running here without issue. It can take a minute or so to connect depending on what your ISP does.

Do you have Do not wait for a RA set in the DHCPv6 client setup?

louis2

I did not use the debug mode, but I think I did test with the "Do not wait for a RA". But of course not in combination with all possible other options. None of the options I tested this morning did work (for IPV6).

I will explicitly test my actual settings in combination with the suggested setting and debug. However I have to wait for a test window :( before I can execut a network interrupting test like this one.
( My kids are staying here at the moment and are using the network for there work).

louis2

@stephenw10

With the describes settings with ^Do not wait for a RA^ added (I think that is necessary), the IPV6 gateway shows

but testing using ^https://test-ipv6.com/^ and pinging ^2606:4700:4700::1001:^ show that it is working in reality.

So, I had to change the config and the gui is not ok, however it seems to work.

Attached, the dhcp log.

20250604_DHCP-messages.txt

Actually running
25.03-BETA (amd64)
built on Thu May 15 16:15:00 CEST 2025
FreeBSD 15.0-CURRENT

stephenw10

The gateway may not respond to ping. If you're requesting a prefix only the gateway will be a link-local IP which means you cannot set an external monitor IP. But it should work otherwise.

That's the same setup I use though I do not set Do not wait for a RA. But that wouldn't change the gateway once it connects:

Name              Monitor                           Source                                Delay   StdDev  Loss  Status  Substatus
BT_DHCP6          fe80::2621:24ff:fed9:623f%pppoe1  fe80::201:21ff:fe01:6775%pppoe1     2.447ms  0.271ms  0.0%  online       none

Gateway log shows dpinger starting:

Jun 4 21:58:32 	dpinger 	83847 	send_interval 2000ms loss_interval 4000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 2000ms latency_alarm 500ms loss_alarm 20% alarm_hold 20000ms dest_addr fe80::2621:24ff:fed9:623f%pppoe1 bind_addr fe80::201:21ff:fe01:6775%pppoe1 identifier "BT_DHCP6 " ```

Phil2025

@stephenw10 said in New PPPoE backend, some feedback:

The gateway may not respond to ping. If you're requesting a prefix only the gateway will be a link-local IP which means you cannot set an external monitor IP. But it should work otherwise.

That's the same setup I use though I do not set Do not wait for a RA. But that wouldn't change the gateway once it connects:
Name              Monitor                           Source                                Delay   StdDev  Loss  Status  Substatus
BT_DHCP6          fe80::2621:24ff:fed9:623f%pppoe1  fe80::201:21ff:fe01:6775%pppoe1     2.447ms  0.271ms  0.0%  online       none
Gateway log shows dpinger starting:
Jun 4 21:58:32 	dpinger 	83847 	send_interval 2000ms loss_interval 4000ms time_period 60000ms report_interval 0ms data_len 1 alert_interval 2000ms latency_alarm 500ms loss_alarm 20% alarm_hold 20000ms dest_addr fe80::2621:24ff:fed9:623f%pppoe1 bind_addr fe80::201:21ff:fe01:6775%pppoe1 identifier "BT_DHCP6 " ```

This is the similar issue I've reported before and we seem to keep getting told one way or the other its not a problem in the code, but it is as it never ever happened with 2.7.2.

On 2.8.0 and the BETAs, more often than not, the monitoring of the IPv6 gateway remains Unknown when PPPoE is connected, even though IPv6 connectivity for clients is up and working just fine. The fix is to jump into Gateways and restart the Gateway service, then its all okay until the next time PPP drops and comes back up again.

louis2

@stephenw10

I have been thinking about the

@Phil2025 said in New PPPoE backend, some feedback:

Do not wait for a RA

I wonder if it is a valid setting!!
Is it not a work around a bug. If the provider is sending a RA and it is not handled correctly by the PPOE-software, is 'Do not wait for a RA' not the wrong way out. !!??

Phil2025

@Phil2025 said in New PPPoE backend, some feedback:

Do not wait for a RA

I wonder if it is a valid setting!!
Is it not a work around a bug. If the provider is sending a RA and it is not handled correctly by the PPOE-software, is 'Do not wait for a RA' not the wrong way out. !!??

I thought I tried that ticked and unticked in the BETAs and it made no difference.

All I know this started with 2.8.0, no previous version had this issue. Also PPPoE is generally just slower to come up in 2.8.0 regardless of using the older code or the new IF_PPPoE. Once up, and the Gateway services restarted to get IPv6 monitoring working, it all seems okay, but it does mean without manual intervention, if PPP goes down for some reason (maintenance or a fault), it doesn't appear to come back properly by itself.

I know its difficult for Netgate to test every ISP in every country, but there is the option to code compare 2.7.2 to 2.8.0 to see what has changed, but I have feeling quite a few scripts relating to PPP links up and down have been completely rewritten, so there isn't that option.

stephenw10

Yes there have been quite a lot of changes to the ppp scripts since 2.7.2.

@louis2 do you also see it start working if you restart dpinger after the connection is up?

RobbieTT

@louis2 said in New PPPoE backend, some feedback:

@stephenw10

I have been thinking about the

Do not wait for a RA

I wonder if it is a valid setting!!
Is it not a work around a bug. If the provider is sending a RA and it is not handled correctly by the PPOE-software, is 'Do not wait for a RA' not the wrong way out. !!??

As it happens I have the 'do not wait' setting set (as per my ISP settings, who thankfully send out unsolicited RAs very infrequently) but when RAs are subsequently received and contain no changes to the original RS, if_pppoe responds to them and triggers services to restart. So it does not provide an artificial 'way out' - if_pppoe just seems very sensitive to unsolicited RAs.

️