New PPPoE backend, some feedback
-
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.
-
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 RAset in the DHCPv6 client setup? -
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). -
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.
Actually running
25.03-BETA (amd64)
built on Thu May 15 16:15:00 CEST 2025
FreeBSD 15.0-CURRENT -
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 noneGateway 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 " ``` -
@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 noneGateway 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.
-
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 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.
-
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?
-
@louis2 said in New PPPoE backend, some feedback:
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.
️ -
I don't think that's if_pppoe dircetly, it has no awareness of IPv6. It's somehow one of the other changes that were added to allow both pppoe types to function.
But you don't see it with if_pppoe disabled? So it must be something that's only triggered when it is.
-
@stephenw10
Surely it still handles the IPv6 setup and configuration during the PPPoE session initialisation, including any subsequent changes from upstream... or am I mistaken?️ -
Nope all that is dhcpc6 once the pppoe is up. It's an odd situation because pppoe does have scope to setup IPv6 like does for v4 (IP6CP) but I have never seen it used. By anything.
For reference: https://www.revk.uk/2011/01/ppp-ipv6cp-vs-dhcpv6.html
And that's straight from RevK so you know it must be true. Or was in 2011!
-
I'm unable to route traffic via an IPv6 gateway on 2.8.0 as I am having the same problem as highlighted by @louis2 where my gateway is pending:
I have tried restarting dpinger, disabling/reenabling the gateway and unchecking
Do not wait for a RAhowever these actions have had no effect.Here are my interface settings using if_pppoe (I have noticed the
Host-Uniqvalue I have set is not visible here but my ISP doesn't require it):
Interestingly I have noticed when viewing the Interface that it does not show the
Gateway IPv6value like is visible for mpd:
There is however a default route set and the gateway address is pingable:
Internet6: Destination Gateway Flags Nhop# Mtu Netif Expire ::/0 fe80::1239:e9ff:feb2:1744%pppoe1 UG 39 1500 pppoe1 PING(56=40+8+8 bytes) fe80::4262:31ff:fe0b:8156%pppoe1 --> fe80::1239:e9ff:feb2:1744%pppoe1 16 bytes from fe80::1239:e9ff:feb2:1744%pppoe1, icmp_seq=0 hlim=64 time=3.586 ms 16 bytes from fe80::1239:e9ff:feb2:1744%pppoe1, icmp_seq=1 hlim=64 time=3.215 ms 16 bytes from fe80::1239:e9ff:feb2:1744%pppoe1, icmp_seq=2 hlim=64 time=3.365 ms --- fe80::1239:e9ff:feb2:1744%pppoe1 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 3.215/3.389/3.586/0.152 msWhen using mpd implementation for contrast (interface settings are identical):
I have seen the following event appear in the logs a few times but unsure if this is of any help:
if_pppoe: pppoe1: failed to set default route 17 -
Hmm so you only see that when using if_pppoe? And IPv4 works fine in both cases?
Probably going to need to compare the system and dhcp logs to see what the difference is there.
-
Hum .. I had to think about the rout-able IPV6 in the picture higher up, so I looked at my PPOE overview.
As you can see in my case there is an link local address, which does not surprise me. And I checked it is pingable
not from some other lan of course!! It is a link local address
-
@benbng I wonder, why you have a MTU of 1500 with PPPoE, usually it is lower.
-
I wonder does the IPV6 address in your TROOLI interface to your IPV6 range or is it an address in the providers infrastructure at the providers side of the PPOE !??
-
@stephenw10 logs below as requested.
mpd
mpdsystem.txt
mpddhcp6c.txtif_pppoe with
Do not wait for a RAchecked
ifpppoesystem.txt
ifpppoedhcp6c.txtif_pppoe with
Do not wait for a RAunchecked
ifpppoesystemnora.txt
ifpppoedhcp6cnora.txtI can confirm IPv4 connectivity is working from clients using both mpd and if_pppoe. When using if_pppoe the firewall itself has IPv6 connectivity (with addresses outside of my ISP's network) however any internal client traffic that matches a firewall rule with the IPv6 gateway is not routed, certainly looks like something to do with pfSense gateways as opposed to a routing/PPP/DHCP issue.
Let me know if I can provide any additional logs.
-
@Bob-Dig there was some talk about this towards the start of the thread; a number of ISPs within the UK support https://datatracker.ietf.org/doc/html/rfc4638 which accounts for the PPPoE overhead and enables devices to use an MTU of 1500 without having to resort to MSS clamping or any of that fun.
