PPPoE: Problems getting an IPv6 address on reconnection and other problems

w0w

Splitting from other thread:
https://forum.netgate.com/post/1218331

Problem description:

Manually disconnecting and reconnecting can result in no IPv6 on WAN, or IPv6 being present on both WAN and LAN, and sometimes it initially appears on WAN but disappears from WAN later.
This behavior present on the 25.03 and not on the 23.09

@stephenw10 said in DNS resolver exiting when loading pfblocker 25.03.b.20250409.2208:

Hmm, but it shows no IP address against the pppoe gateway and the RTT at 0.5ms seems too low to be real.
This is what it looks like when I get only Ipv4 and everything is working except ipv6

Sorry, all IP addresses are present on the interface—there’s just no default gateway. I believe dpinger still works because an automatic route to the ISP-gateway IP is still in the routing table. The RTT is so low because dpinger is using the ISP-gateway IP address, so that’s fine. The connection is a fiber line that runs directly from my house to the ISP gateway.
I suspect that the missing uptime entry and default route are caused by a race condition, and it doesn’t occur very often. The failure to obtain IPv6, however, is more frustrating.
So far I have tested boot environment with old 23.09 version and can just hit disconnect WAN and then connect wan without any issues.

w0w

Got this uptime bug again:
daf7a376-e397-42bd-81b6-3342a69d6bbe-{82A34248-524A-4260-A170-6E7CA8E1B020}.png

dev: lagg3 state: session
	sid: 0x13bb PADI retries: 0 PADR retries: 0 time: 00:01:11
	sppp: phase network authproto auto authname "uuuuuu" peerproto auto
	dns: xxx.7.0.x3 xxx.7.9.x4

Some spam in log also

2025-06-18 21:53:38.347634+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.328776+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.311046+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.292505+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.277009+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.253711+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.239866+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.226714+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.213645+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:
2025-06-18 21:53:38.200538+03:00 	php 	51068 	/usr/local/sbin/ppp-ipv6: Gateway, switch to:

stephenw10

Hmm, odd. That's with the new test patch for if_pppoe?

w0w

@stephenw10 said in PPPoE: Problems getting an IPv6 address on reconnection and other problems:

That's with the new test patch for if_pppoe?

Yes.

One more thing: the link always comes up fine after a clean boot. Also I have better luck if I don’t click Connect WAN immediately after the page reloads from Disconnect WAN. It feels as though something is still running and hasn’t fully released when the new session starts.

Also, this message seems new—I don’t recall seeing it before the last build/patch :

2025-06-19 05:35:10.946591+03:00 	kernel 	- 	if_pppoe: pppoe0: failed to clear IP address: 49

stephenw10

Hmm OK. And without the patch what behaviour were you seeing? Just failing to pull an IPv6 address?

w0w

@stephenw10
This need to be tested. Hope I'll do it soon.
Also I've seen that another one patch coming...

stephenw10

Yup, work on this is ongoing!

w0w

Some additional testing has been done. The uptime bug and the missing default route were probably caused by a custom script that I forgot to shut down. The issue seems impossible to reproduce when the script is disabled, or at least it seems not so easy to reproduce without this script.

The bad news is that IPv6 behaviour is still almost the same: most of the time I get only IPv4 or only IPv6 on the WAN interface, and then it disappears. However, almost every time I reboot the firewall I get both IPv4 and IPv6 running, so the problem occurs only when reconnecting.
And without the patch I don't see any difference.

I wonder, then, what the difference is between bringing up PPPoE during the firewall’s boot and restarting PPPoE manually or when it is triggered by other causes?

stephenw10

Ah, OK.
So, with our testing patch, what do you see in the logs after disconnecting and reconnecting the pppoe WAN in Status > Interfaces?

I forget if you were previously seeing RAs from your ISP? But the patch is expected to allow pulling an IPv6 lease when ISPs do not send an RA.

w0w

Disconnection log disconnect_masked.txt
Connection log connect_masked.txt
I don’t see anything unusual—perhaps only the CARP storming. I use CARP only on WAN2 and the LAN subnets, not on the PPPoE WAN.

@stephenw10 said in PPPoE: Problems getting an IPv6 address on reconnection and other problems:

I forget if you were previously seeing RAs from your ISP?

Every 3 seconds I receive RA packet from ISP. Before the early patch, I was getting a massive storm of log entries and all services kept restarting continuously, and so on, because of that. Now I have problem with receiving Ipv6 but only on reconnection. A clean boot simply works, and in rare cases, just saving the WAN interface settings and applying the changes works too. The same behavior first time occurred on the first 25.03 beta available, without new backend active.

stephenw10

Hmm, so if you disconnect the pppoe and reconnect it in Status > Interfaces what do you see logged?

w0w

@stephenw10
Yes

stephenw10

Um I was hoping for an actual log to look through.

w0w

@stephenw10
I just wasn’t fully awake when I read the message — for some reason, it seemed like the question was worded differently.
The last log I posted was actually from when I pressed disconnect and then arter it disconnected, connect.

stephenw10

Could be my turn to find more coffee then! Where is that log?

w0w

@w0w said in PPPoE: Problems getting an IPv6 address on reconnection and other problems:

Disconnection log disconnect_masked.txt
Connection log connect_masked.txt

My FF opens those attachments just fine.

stephenw10

Ha, OK. Definitely more coffee required! Somehow read straight past those.

w0w

pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
	description: WAN
	options=0
	inet xx.52.22.101 --> yyy.7.29.248 netmask 0xffffffff
	inet6 fe80::aab8:e0ff:fe02:6zz9%pppoe0 prefixlen 64 scopeid 0x11
	inet6 2001:1b28:b248:e39:NNNN:e0ff:fe02:6zz9 prefixlen 64 autoconf pltime 604800 vltime 2592000
	groups: pppoec
	nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>

This is what I see when I get IPv6 only on WAN. Sometimes it shows also "detached" in Ipv6 options

If I run rtsol pppoe0 I am getting

rtsol: pppoe0 does not accept Router Advertisement.

So if I force it by issuing

ifconfig pppoe0 inet6 -ifdisabled -no_radr accept_rtadv
rtsol -F pppoe0

This results in the same outcome — I still receive an IPv6 address marked detached or not and after some time it disappears.

On reboot of firewall I am getting

pppoe0: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
	description: WAN
	options=0
	inet xx.52.5.227 --> yyy.7.29.248 netmask 0xffffffff
	inet6 fe80::aab8:e0ff:fe02:6zz9%pppoe0 prefixlen 64 scopeid 0x10
	inet6 2001:1234:b248:e39:NNNN:e0ff:fe02:6zz9 prefixlen 64 detached autoconf pltime 604800 vltime 2592000
	inet6 2001:4321:d248:ffff:f8b3:abab:1435:769f prefixlen 128 pltime 86400 vltime 172800
	inet6 2001:4321:d248:ffff:49e6:baba:d204:50b8 prefixlen 128 pltime 86400 vltime 172800
	groups: pppoec
	nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>

IPv6 works fine then.

I am not quite sure what it means, but…

EDIT:
It turns out that when I enable the “Do Not Wait for RA” option, the interface receives all addresses just fine.
Curiously, I recall having trouble obtaining addresses even with that option enabled. I probably need to run some more tests—maybe the other settings I tried in combination are now doing the trick.

stephenw10

Ah, OK. So, yes, if your ISP requires that then it should now work correctly with the new patch.

So with that set is it working as expected for you?

w0w

@stephenw10 said in PPPoE: Problems getting an IPv6 address on reconnection and other problems:

So, yes, if your ISP requires that then it should

It was not required until 23.05.
Of course, this doesn’t necessarily mean that it worked without that option in version 24.11, but it definitely works without it in 23.09. In fact, the need to enable this option in earlier alpha versions of 23.05 is what originally led to the creation of a patch, which was supposed to fix the issue that occurred without this option enabled. And logically, the problem—namely, log spam and endless restarts of services triggered by each RA received from the ISP—did stop, so I assumed I no longer needed the option.

Apologies for the slight confusion... But again, how is one supposed to make sense of all these modern connection and address assignment algorithms, when in one version of pfSense I need to enable this option, and in another, everything works fine without it?

Definitely will test later and report back with this option enabled.