AX88U + 386.8 IPv6 intermittent

[torchddv]

Same problem. Works for a while, then dies.

Trace route suggests the problem is in the router. From the computer, it hits the router at ::1, then all requests time out from there on. From Network Tools tab in the router, all Trace Route attempts time out.

Not sure what this log entry means, but it looks weird:

Nov 28 10:55:45 kernel: ^[[0;33;41mBLOG ERROR blog_request :nf_conn: blog_key corruption when adding flow net_p=ffffffc02b9dc1d0 dir=1 old_key=0xfffffffe new_key=0xa0000060
Nov 28 10:55:45 kernel: ^[[0m

 

[Ripshod]

Just pinged facebook

Pinging 2a03:2880:f12f:83:face:b00c:0:25de with 32 bytes of data:
Reply from 2a03:2880:f12f:83:face:b00c:0:25de: time=203ms
Reply from 2a03:2880:f12f:83:face:b00c:0:25de: time=209ms
Reply from 2a03:2880:f12f:83:face:b00c:0:25de: time=194ms
Reply from 2a03:2880:f12f:83:face:b00c:0:25de: time=195ms

Ping statistics for 2a03:2880:f12f:83:face:b00c:0:25de:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 194ms, Maximum = 209ms, Average = 200ms

Really not understanding yours, unless like I said something else is interfering. I can't reason why but could ipv6 be blocked by your isp? Is that even a thing?

 

[Ripshod]

Just realised something that I've done differently. For Routed IPv6 I use the /64 rather than the /48 the guide suggests. Hope I've not got that wrong but it works.

 

[torchddv]

Yet mine is stable 6in4 via HE (tunnelbroker) on AX88U with the 388.1beta3 firmware. There must be something interfering but what is anybody's guess.

Afterthought:
Have you added /jffs/scripts/wan-event scipt?
Probably a silly question.

Yes, I have. It calls wan-connected, which updates the tunnel endpoint IP. That works perfectly; every time I compare my endpoint on the tunnelbroker account webpage it matches my current public IPv4 IP address.

I just completed the nuclear option -- went back to 386.8, restored the router to factory defaults and started over.

It seems to be pinging google OK so far, BUT test-ipv6.com reports:

"Danger! IPv6 sorta works - however, large packets appear to fail, giving the appearance of a broken website. If a publisher publishes to IPv6, you will believe their web site to be broken. Ask your ISP about MTU issues; possibly with your tunnel. Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big). "

 

[Ripshod]

You are adjusting the MTU on the router and in the tunnelbroker settings (advanced) to the same value aren't you? If you've done everything as per the wiki guide apart from /64 routed Ipv6 and the aforementioned MTU settings on both ends then I'm at a total loss.

 

[torchddv]

You are adjusting the MTU on the router and in the tunnelbroker settings (advanced) to the same value aren't you? If you've done everything as per the wiki guide apart from /64 routed Ipv6 and the aforementioned MTU settings on both ends then I'm at a total loss.

Actually, no, I wasn't. Didn't realize i had to change the tunnelbroker end too.

It looks like their end is set to 1480.

 

[Ripshod]

Actually, no, I wasn't. Didn't realize i had to change the tunnelbroker end too.

It looks like their end is set to 1480.

You can easily change it on the server - it's just a slider with an update button. The MTU must match on both ends of the connection and it'll always be lower that your isp's MTU.

 

[torchddv]

Ok, since the factory reset, ping tests show no interruption in IPv6 connectivity. I can reach IPv6 sites (including this site) but sometimes with considerable lag. As noted above, test-ipv6.com suggests a problem with large packets, ipv6-test.com just reports IPv6 is not working.

Reading elsewhere, I have learned that the ISP could also be using some sort of tunnel, which would add it's own overhead to each packet, which could explain the errors with an MTU setting of 1480.

I have tried adjusting MTU at both ends down as low as 1440, with the same results. I'm gonna assume HE knows how to set up their end of the tunnel by now. Which brings us to: "Check your firewall to make sure that ICMPv6 messages are allowed (in particular, Type 2 or Packet Too Big). "

Now, iptables are not really my strong suit (hell, none of this is; most of the time I'm floundering around in the dark here, let's just add iptables to the list). To ensure type 2 packets are allowed, I'm thinking I add a line to firewall-start script:
ip6tables -A INPUT -p ipv6-icmp --icmpv6-type 2 -j ACCEPT

Does that sound right, or will it conflict with something in the pre-packaged Asus - Merlin IPv6 firewall rules?

 

[Ripshod]

As far as the firewall goes you shouldn't have to do anything. Which guide are you following. I know with one it relies on ddns - never got that one to work.
This guide works (with the script instead of ddns) - https://github.com/RMerl/asuswrt-merlin.ng/wiki/IPv6-tunnelling

I'm no expert on this. I only have personal experience.

 

[torchddv]

I am set up like this:

ipv6 recipe for asuswrt-merlin via hurricane electric

It took me a bit to get this going so i thought i would share. When you are done you will have IPv6 in your home for all your devices. High level instructions 1. sign up for a (free!) tunnel account @ http://tunnelbroker.net/ 2. change your DDNS settings in asuswrt to reset your v4 IP if it...

www.snbforums.com

As far as I can see, the principle difference between the two sets of instructions are that the set you just provided indicate the lan prefix should be /48, whereas the lan prefix in the directions I followed is /64.

 

[Ripshod]

I am set up like this:

ipv6 recipe for asuswrt-merlin via hurricane electric

It took me a bit to get this going so i thought i would share. When you are done you will have IPv6 in your home for all your devices. High level instructions 1. sign up for a (free!) tunnel account @ http://tunnelbroker.net/ 2. change your DDNS settings in asuswrt to reset your v4 IP if it...

www.snbforums.com

As far as I can see, the principle difference between the two sets of instructions are that the set you just provided indicate the lan prefix should be /48, whereas the lan prefix in the directions I followed is /64.

Also you've used DDNS, whereas I just used the script method. Using DDNS you're relying on the DDNS server updating (up to 20 minutes with noip by my experience). Using the script method it's virtually instant.

 

[torchddv]

Sorry, no, I'm not using DDNS to update the tunnel endpoint, I'm using a script ("wan-connected", which is called by "wan-event"). The update is -- as you say -- almost instantaneous.

 

[Ripshod]

Danger! IPv6 sorta works - however, large packets appear to fail,

I've just reread this. Could it really be that simple - MTU? Iirc I got the same error early on and tested with lower MTUs til it all just worked.