Posted: Sat May 24, 2025 15:37 Post subject: Loss of IPv6 WAN routing - MX4200 v2 and R7800
Hi All,
I noticed a few weeks ago following a reboot that my R7800 running dd-wrt had lost its IPv6 connectivity.
Further investigation revealed that it happens a few minutes after starting up, at which point it loses the IPv6 default route. I've read numerous posts on these forums with reports of similar issues and have tried various suggested solutions to no avail, including turning off the security option to block WAN multicast communication and enabling allmulti on the WAN interface.
I've since installed dd-wrt on a second router, a Linksys MX4200 v2, and am seeing the same issue.
I have installed rdisc6 (via Entware) and set up a cron entry as here (but running it every minute):
The one thing that does fix it is manually clicking on Save & Apply in the IPv6 settings GUI page (and possibly elsewhere). The connectivity then comes back and is stable (with the regular receipt of RA messages), however having to do that manually each time the rooter is rebooted isn't really the solution I'm looking for.
Wondering if anyone has any other suggestions, or can advise how to replicate the Save & Apply behaviour from the command line so, if nothing else, I can script that to happen a few minutes after the router restarts.
Which I believe would be similar to clicking Save & Apply, but Save & Apply may do more than just this. _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: VLANs, Samba, WG, Entware - r60xxx
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk over 5ghz - r60xxx
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r60xxx
- Linksys MX4300: (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r60xxx
- Linksys MR7350: WDS Station for extended Ethernet r60xxx
- Linksys MR7500, MX8500: None in production. Just testing. r60xxx
- OSes: Fedora 40, 10 RPis (2,3,4,5), 23 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
- Forum member #248
Joined: 07 Jan 2025 Posts: 301 Location: Bethel Park, PA, USA
Posted: Sun May 25, 2025 0:50 Post subject:
Do you have the NSS settings turned on? I had the same problem with IPv6 on my R7800. See this thread: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=336594&highlight=. I had posted workaround code in the first post, but the ultimate solution was to either switch from one of the NSS settings to SFE, or to turn off Multicast filtering in the Security/Firewall tab. _________________ Formerly dpp3530 Linksys MX4300
Gateway, 2 wired APs, NSS-ECM , Clock 1651MHz
VAPs on wlan0 and wlan1 for guest/IOT devices
IPv4 & IPv6 (Prefix Delegation)
Static Leases & DHCP
SmartDNS (DOQ using NextDNS, Cloudflare), DNSMasq
Wireguard and OpenVPN server
2.4GHz: dd-wrt, AX Only, ACK Timing 2000, WPA3 SAE & WPA2 w/AES
5GHz: dd-wrt, AX/AC/N Mixed, ACK Timing 2000, WPA3 SAE & WPA2 w/AES
Verizon Fios, 500/500Mbps
Do you have the NSS settings turned on? I had the same problem with IPv6 on my R7800. See this thread: https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=336594&highlight=. I had posted workaround code in the first post, but the ultimate solution was to either switch from one of the NSS settings to SFE, or to turn off Multicast filtering in the Security/Firewall tab.
Unfortunately, neither of those solve the problem for me (my Shortcut Forwarding Engine option was already set to SFE). I've just tried disabling the QCA NSS Subsystem as well but that also doesn't help.
I suspect it may in part be down to my ISP (UK Toob) since the issue I'm seeing isn't quite the same as those who have been able to resolve it and I only noticed a problem on my R7800 on rebooting a few weeks ago and not when I first switched to Toob and updated to a newer version of dd-wrt.
However, the fact that it happens after a reboot, but can be resolved by hitting Apply & Save - and, I assume, Toob customers using the supplied router/build aren't having the same problem - suggests that router behaviour is a factor as well.
On the plus side, service init_start start does also seem to bring it back to life so I can probably at least script a work-around.
If the command @lexridge provided works, you could always add
Code:
Sleep 60
service init_start start
to your Startup script in Administration/Commands. Would save you from having to Apply.
I put this in my custom script, which the Startup script runs in the background
Code:
#Periodically monitor for loss of IPv6 connectivity
INTERVAL=15
INTERVAL2=600 # Minimum period between restarts
PACKETS=1
TARGET1="<ISP DNS server 1 IPv6 address>"
TARGET2="<ISP DNS server 2 IPv6 address>"
while sleep $INTERVAL
do
RET=`ping -6 -c $PACKETS $TARGET1 2> /dev/null | awk '/packets received/ {print $4}'`
if [ "$RET" -ne "$PACKETS" ]; then
RET=`ping -6 -c $PACKETS $TARGET2 2> /dev/null | awk '/packets received/ {print $4}'`
if [ "$RET" -ne "$PACKETS" ]; then
sleep $INTERVAL
RET=`ping -6 -c $PACKETS $TARGET1 2> /dev/null | awk '/packets received/ {print $4}'`
if [ "$RET" -ne "$PACKETS" ]; then
RET=`ping -6 -c $PACKETS $TARGET2 2> /dev/null | awk '/packets received/ {print $4}'`
if [ "$RET" -ne "$PACKETS" ]; then
logger -s -t IPv6 Monitor "[$$]:Services restarting"
service init_start start
logger -s -t IPv6 Monitor "[$$]:Services restarted"
sleep $INTERVAL2
fi
fi
fi
fi
done
payload length: 24) fe80::d281:c5ff:fe9e:8913 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 24