New PPPoE backend, some feedback

stephenw10 · May 3, 2025, 5:34 PM

Hmm, interesting.

I expect to not have that checked because the dhcp is set to go over PPPoE. It should only try to pull a lease once the PPPoE is up and remote server sends an RA over it. But that does depend on the frequency the ISP sends at. One of the other issues we are seeing is with ISPs that send RAs at high frequency, like 10s intervals, and trigger events at each.

But I suspect the difference here is that the old backend only marks the interface up once it's actually connected and if_pppoe is seen as UP as soon as it's created. If dhcp6c doesn't wait for an RA it will immediately try and fail and then.... get stuck in some fail-loop!

We are changing that behaviour now so it may be fixed in the next build anyway.

RobbieTT · May 3, 2025, 9:49 PM

@stephenw10 said in New PPPoE backend, some feedback:

Hmm, interesting.

I expect to not have that checked because the dhcp is set to go over PPPoE. It should only try to pull a lease once the PPPoE is up and remote server sends an RA over it.

Looking forward to the changes.

My ISP RA's are sent reasonably infrequently so once the PPPoE session is up the client router (pfSense) should send an RS upstream and get the RA straight back. Occasionally an RA is captured first but typically the RA used will be triggered by the RS.

The days of waiting obediently for an RA should be confined to history (well, whenever the replacement RFC came out, which is a number of years ago now). ISPs that deliberately machine-gun out unsolicited RAs should be sent a burning copy of the standards.

️

RobbieTT · May 6, 2025, 12:15 PM

@stephenw10

The 171.diff patch really improves things. New text file with logs, dmesg -a and my remaining comments sent direct.

️

stephenw10 · May 6, 2025, 2:39 PM

Hmm, I can't replicate that FQDN access issue. How does it fail when you do that?

RobbieTT · May 6, 2025, 3:21 PM

@stephenw10

The GUI stalls and I get this:

With the fqdn it's like as soon as the WAN is lost it forgets that local access is still available. Perhaps unbound is restarting and local look-ups are dropped but I'm not really sure of the cause. I'm not using Kea, if that is a factor.

If I use the GUI via the IP address instead and take the PPPoE interface down / up then the GUI stays alive.

️

stephenw10 · May 6, 2025, 3:30 PM

Hmm, yeah that does seem like it must be an Unbound issue. I guess I'm not seeing it here because I'm not using that box for DNS...

patient0 · May 6, 2025, 6:02 PM

Just a reference: There is another thread where a user reports an issue with connecting to the webGUI (503 error) after upgrading from 24.11 to 25.03-BETA and then switching on the if_pppoe module:

Problems after enabling if_pppoe

w0w · May 6, 2025, 6:24 PM

@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 · May 6, 2025, 6:44 PM

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

RobbieTT · May 6, 2025, 7:58 PM

@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 · May 7, 2025, 3:14 PM

@RobbieTT said in New PPPoE backend, some feedback:

171.diff

Where can I get it?

stephenw10 · May 7, 2025, 3:17 PM

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

w0w · May 7, 2025, 5:32 PM

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

RobbieTT · May 9, 2025, 1:49 PM

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