What's new

IPv6 tunnel instability with 378.51 on RT-N66U

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

torchddv

Regular Contributor
I have been running 378.51 for a couple of days now. Did a factory reset and manual configuration after installing it. IPv6 is via an HE tunnel. The wan-start script correctly configures the tunnel on boot. Included in my wan-start script is some code to write an entry showing the tunnel endpoint update result in a persistent log on the USB memory stick every time wan-start is run. I am not using any other advanced features (eg: VPN, Samba, etc.), however I added entware-based DNSCrypt instances for both IPv4 and IPv6 (which I did not have running on the previous firmware, which was stable for months at a time).

Everything works properly initially.

However, after a few hours, IPv6 connectivity with the outside world fails. Devices still receive an IPv6 address, and can ping each other on the home network side of the router, but cannot connect to or ping external IPv6 addresses. Previously I have seen similar symptoms when the tunnel endpoint failed to update an external IP change, however, the persistent log does not show any change during that time and manually looking up the current endpoint value on the HE Tunnelbroker web panel shows it matches my current external IP.

So far, it seems to happen when I'm not around or overnight. The router log overwrites the beginning, and I can't see any entry showing what might have failed (not that I'm an expert at reading router logs anyway!) I can see that the IPv4 instance of DNSCrypt successfully obtained new certificate keys (seems to happen about once an hour), but there are repeated failures when the IPv6 instance tries to update, suggesting that the IPv6 connectivity failed prior to the earliest logged event.

It would be nice if someone could simply say "Oh yes, we know all about that, just change x to y and all will be well." However, I have been searching the forum and can't find the easy solution. So can someone suggest the next step to diagnose the problem? Maybe a script that will create a persistent log on the memory stick of possible clues to watch for? (Please speak slowly and use small words: I'm not very good at this stuff!)
 
3-1/2 days of uptime now. I have no idea why it's working properly now. Maybe an ISP issue?

Anyway, I would still appreciate it if someone could point me in the right direction for preserving logs to the USB drive so they are still available following a reboot or when over-written.
 
I notice the same thing each time even with recent v53 FW. The tunnel works from 15min to 12hours then dies, for ping and traceroute from the router too. Die time very depends on the tunnel/v6in4 MTU, it is ~15min with 1460 and up to 12hours with 1380. Pressing Apply button on IPv6 tab without changing anything (or reboot) fix HE tunnel temporarily for another interval. Since 6in4 tunnels are stateless, this is clearly not HE tunnel bug since it does not know anything about router reboot or v6in4 interface recreated. Another workaroud is to set tunnel/v6in4 MTU to 1280, it works at least 24h, I can't say for more because my provider drops connection once a day. There is nothing in syslog and it looks like linux kernel bug. HE site suggest workaround for some Linux routers with agressive anti-spoofing: ip tunnel 6rd dev v6in4 6rd-prefix $V6PTPNET/64 6rd-relay_prefix $TSERVV4IP/32, but it change nothing in my case.
 
Last edited:
It is not MTU problem since I have it when downloading many torrents too even with MTU 1280. I found that it is software acceleration problem, namely Cut Through Forwarding. When I disable CTF in NAT Acceleration, 6in4 tunnel works with any MTU unlimited time. See also another user report at ASUS forum: http://vip.asus.com/forum/view.aspx...d_id=11&model=RT-AC66U&page=1&SLanguage=en-us

Same thing here on AC56 with 380.57. I didn't notice this on 378.56_2 though. Luckily my WAN speed doesn't warrant the need for CTF so I'll have it disabled for now and will have to see if IPV6 connectivity remains stable.
 
I think I also had this tunnel instability issue, I've disabled the CTF (it's on Lan > switch control if you are looking for it), turned the ip6 firewall back on and will monitor tunnel to see if continues to go down.

I'm on 380.57 merlin.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top