hartacus
New Around Here
I use native IPv6, my ISP provides a static /64. I also use a ULA assigned to the router via 'dhcpc-event' script, together with a corresponding range of ULAs provided to LAN devices via 'dnsmasq-postconf' script, to help Pi-hole resolve local hostnames of IPv6 clients sensibly.
After updating to asuswrt-merlin 3006.102.4, I have noticed that the IPv6 ULA assigned to the router is being periodically removed.
The 'dhcpc-event' script checks whether the ULA exists in the output of ip addr show dev
and if not it adds the ULA via
The system log shows that it's being silently removed (not sure by what), and then re-added again next time the script runs - the script logs a different message when the ULA is found vs when the ULA is added, and it's intermittent.
Prior to the update, the script would log the message when the ULA was added at boot, and then subsequent messages would just be saying that the ULA was found over and over again.
Has anything changed, like flushing all IPv6 addresses when receiving DHCPv6 assignment from the ISP, or anything else that would cause the address to drop?
IPv6 connectivity is fine through all this, it's just messing with the ULA addressing and consequently breaking Pi-hole IPv6 client name resolution.
After updating to asuswrt-merlin 3006.102.4, I have noticed that the IPv6 ULA assigned to the router is being periodically removed.
The 'dhcpc-event' script checks whether the ULA exists in the output of ip addr show dev
Code:
ip addr show dev br0
Code:
ip -6 addr add [ULA]/64 dev br0
Prior to the update, the script would log the message when the ULA was added at boot, and then subsequent messages would just be saying that the ULA was found over and over again.
Has anything changed, like flushing all IPv6 addresses when receiving DHCPv6 assignment from the ISP, or anything else that would cause the address to drop?
IPv6 connectivity is fine through all this, it's just messing with the ULA addressing and consequently breaking Pi-hole IPv6 client name resolution.