WAN_DHCP6 Stuck Pending
-
I just upgraded to the latest 2.7.0 snapshot. It's working fine, including IPv6, but WAN_DHCP6 is stuck pending. There is no dpinger process running, possibly because the IPv6 gateway address doesn't seem to be being detected, at least, it's not being displayed in Interface status. If I enter the address of the gateway, it works fine. Previously, before upgrading to this version of the snapshot, it was not necessary to enter the address of the gateway. It just worked.
-
But it is pulling a dhcpv6 lease correctly?
If you restart dpinger does it start to work?
-
@stephenw10 said in WAN_DHCP6 Stuck Pending:
But it is pulling a dhcpv6 lease correctly?
If you restart dpinger does it start to work?
It is getting a prefix properly. The only symptom is that the gateway never goes to online status. The only way I can get dpinger to start is to manually set the gateway address. If l leave it blank, dpinger will not start.
-
Is it only pulling a prefix? Are the WAN and gateway using link-local addresses?
-
The ISP only provides a prefix, not an address, so the WAN address is link-local. The address of the gateway is also link-local. As I said previously, everything is working fine, except in the interface status, there is no IPv6 address for the gateway and dpinger will not start unless I manually enter the address of the gateway as the address to monitor.
This has always been the case for this ISP. I have two instances of pfSense running. One is running 2.6.0 release and this problem is not occurring. The other is running 2.7.0-DEV and this problem started when pfSense switched to BSD 14.
-
Hmm, OK. Yeah I'd expect that work. Let me see if I can replicate it....
-
My WAN_DHCP6 gateways here appear to be fine, even on a fresh install.
That said, I am having an issue with gateways on IPv6 GIF tunnel interfaces (#11545), which could maybe be related, though it's hard to say without more evidence.
-
@jimp said in WAN_DHCP6 Stuck Pending:
My WAN_DHCP6 gateways here appear to be fine, even on a fresh install.
That said, I am having an issue with gateways on IPv6 GIF tunnel interfaces (#11545), which could maybe be related, though it's hard to say without more evidence.
Are your systems showing a Gateway IPv6 address? If so, that might explain the difference. I've mentioned before that the Nokia routers used by my ISP do not set the M or O flag in the RA message. If pfSense is relying on rtsol to run a script based on the M or O flag to set variables, this might explain why the Gateway IPv6 address is not being set. I guess the router is not using the M or O flag because the DHCPv6 messages have already been exchanged.
If it would help, I can post the packet contents captured by wireshark.
-
Mmm, I would expect that to have changed going to 2.7 though. At least not intentionally!
-
In case my post isn't clear, when I said this worked before I upgraded to the latest 2.7.0 snapshot, I meant before the snapshot where pfSense changed over to FreeBSD 14. When pfSense changed over to FreeBSD 14, this issue emerged.
