New PPPoE backend, some feedback

louis2

@stephenw10

Yes only IPV6, there has never been an issue with IPV4.

Good idea to switched back to the old PPOE. I did that for a moment ... the gui was OK again.

A bit of further testing showed ... could still not ping iPV6 ....
So I did search further ......

I found a ... test rule blocking IPV6 (for my vlan only)
After removing the rule ... IPV6 worked.

So I switched back to the kernel PPPOE .... which also worked ..... with the GUI problem ....

Sorry Sorry !

I stay on the kernel PPPOE version for now.

stephenw10

Ah, a rogue test rule. That will do it!

perrin

@stephenw10 In my case I can also confirm an issue with IPv6 after the interface has been connected for some time.

in my case it was >20days. Had to reconnect the interface and IPv6 never came back up.

[25.07.1-RELEASE][root@pfSense.xxxxx]/root: pppcfg pppoe0
        dev: vtnet0.501 state: session
        sid: 0x189 PADI retries: 0 PADR retries: 0 time: 00:04:59
        sppp: phase network authproto auto authname "xxxx@xxx" peerproto auto
        dns: 89.58.97.56 89.58.97.57
[25.07.1-RELEASE][root@pfSense.xxxx]/root: ifconfig pppoe0
pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN
        options=0
        inet 89.58.xx.1 --> 185.232.xx.x1 netmask 0xffffffff
        inet6 fe80::be24:11ff:fea6:745e%pppoe0 prefixlen 64 scopeid 0x21
        groups: pppoec
        nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD>

pppoe log seems normal in debug mode:

Oct 14 11:59:21 	kernel 		if_pppoe: pppoe0 (8864) state=3, session=0x189 output -> e2:f6:2d:4a:d9:8f, len=16
Oct 14 11:59:21 	kernel 		if_pppoe: pppoe0: lcp output <echo-reply id=0x26 len=8
Oct 14 11:59:21 	kernel 		if_pppoe: pppoe0: got lcp echo req, sending echo rep
Oct 14 11:59:21 	kernel 		if_pppoe: pppoe0: lcp input(opened): <echo-req id=0x26 len=8

don't see any DHCPv6 packets on the interface:

[25.07.1-RELEASE][root@pfSense.xxx]/root: tcpdump -i pppoe0 -vvv '(port 67 or port 68)'
tcpdump: listening on pppoe0, link-type PPP_ETHER (PPPoE), snapshot length 262144 bytes
0 packets captured
32 packets received by filter
0 packets dropped by kernel

rebooting the firewall brings back IPv6 as expected.

stephenw10

Hmm, anything in the dhcp logs during that time? Do you have verbose logging enabled for the dhcpv6 client? If not enable it in Sys > Adv > Networking.

perrin

@stephenw10 nothing in the logs for the DHCP client. I will enable the debug logging and check the logs upon the next reconnect

perrin

@stephenw10 i did some more tests and i can confirm the behaviour of my firewall with if_pppoe as follows:

first connect after boot works in all cases, so 100% success.
disconnecting and reconnecting the interface does not bring ipv6 back up.
the state of the interface in this case is normal, nothing in the logs, even with debug mode turned on in DHCP client, no DHCPv6 packets in tcpdump

ifconfig pppoe0
pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN
        options=0
        inet 89.xx.xx.xx --> 185.xx.xx.xx netmask 0xffffffff
        inet6 fe80::be24:11ff:fe1d:89fb%pppoe0 prefixlen 64 scopeid 0x23
        groups: pppoec
        nd6 options=121<PERFORMNUD,AUTO_LINKLOCAL,NO_DAD

pppcfg pppoe0
        dev: vtnet0.501 state: session
        sid: 0xba PADI retries: 0 PADR retries: 0 time: 00:02:29
        sppp: phase network authproto auto authname "xxxx@xxxx" peerproto auto
        dns: 89.58.97.56 89.58.97.57

so, everything looks completely normal.
then I was testing around and found ppp-ipv6

so I thought, lets try

ppp-ipv6 pppoe0 up

and, bam -> we've got IPv6 afterwards:

ifconfig pppoe0
pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
        description: WAN
        options=0
        inet 89.xx.xx.xx --> 185.xx.xx.xx netmask 0xffffffff
        inet6 fe80::be24:11ff:fe1d:89fb%pppoe0 prefixlen 64 scopeid 0x23
        inet6 2a11:fb80:xx:xx:xx:xx:fe1d:89fb prefixlen 64 autoconf pltime 604800 vltime 2592000
        groups: pppoec
        nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>

so, no idea why DHCPv6 does work upon boot, but not upon subsequent reconnects. I suspect some sort of timing issue - maybe DHCPv6 is started too early or maybe it is not started at all.

any ideas?

w0w

Another thing I’ve seen mentioned somewhere already is that it would be very useful to correctly terminate PPPoE sessions on reboot/shutdown and whenever the parent interfaces go into any “down” state. For example, my ISP does not accept any new connections while a stale PPPoE session exists. This almost always happens on reboot. If I just run ifconfig pppoeX down and then reboot, PPPoE works on the next boot.

Phil2025

@perrin @stephenw10

Just wanted to add I'm still seeing the same issues as others here, but as my ISP via fibre is very reliable with the connection remaining up for months I've just accepted the bug and work around it with a gateway restart.

In the last week they had a hardware problem that caused the connection to flap and I did notice sometimes IPv6 came up okay, other times it didn't.

I will try the ppp-ipv6 pppoe0 up command next time rather than a gateway service restart.

Thanks to everyone looking into this.

stephenw10

@Phil2025 said in New PPPoE backend, some feedback:

I will try the ppp-ipv6 pppoe0 up command next time rather than a gateway service restart.

Hmm, yeah, that would be an interesting result if you can replicate it.

Phil2025

@stephenw10 I tried ppp-ipv6 pppoe0 up and it made no difference. In my case IPv6 works fine, its just the gateway monitoring doesn't go 'online', so I need to restart the Gateway service.

IPv6 may continue to work in my case because the subnets are hard coded in the LAN pages, so configuration is manual of IPv6 addresses for each LAN, and the ISP just sends through anything in my /48.

Hope that helps.