So I think this is right for pinging the WAN Gateway address on the ppp0 interface. It works.
John@RT-N66U-1FF0:/tmp/home/root# ping -6 fe80::ea4:2ff:fe3e:1 -I ppp0 PING fe80::ea4:2ff:fe3e:1 (fe80::ea4:2ff:fe3e:1): 56 data bytes 64 bytes from fe80::ea4:2ff:fe3e:1: seq=0 ttl=255 time=4.633 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=1 ttl=255 time=4.817 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=2 ttl=255 time=5.373 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=3 ttl=255 time=4.870 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=4 ttl=255 time=5.010 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=5 ttl=255 time=4.709 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=6 ttl=255 time=4.704 ms 64 bytes from fe80::ea4:2ff:fe3e:1: seq=7 ttl=255 time=5.035 ms --- fe80::ea4:2ff:fe3e:1 ping statistics --- 8 packets transmitted, 8 packets received, 0% packet loss round-trip min/avg/max = 4.633/4.893/5.373 ms
The only packets I'm seeing in the log as being dropped relate to IPv4 addresses.
Here's the current routing table information if that helps. It means very little to me.
So some progress in that we know you can ping6 to the upstream BT router.
From the CLI is there a 'conntrack' command option to show the iptables firewall connection table? If you start a ping6 from a LAN client check to see if the traffic is being sent out and a connection table entry created.
Here's an example to list ICMPv6 traffic, and this shows an entry where the ping has been sent out, but not responded to as seen be the UNREPLIED state.
root@erx1:/home/smf22# conntrack -L -f ipv6 -p icmpv6 icmpv6 58 29 src=2a00:23c5:xxxx:yyyy:250:56ff:fe90:c6c3 dst=2a00:23c5:aaaa:bbbb::1 type=128 code=0 id=28358 [UNREPLIED] src=2a00:23c5:aaaa:bbbb::1 dst=2a00:23c5:xxxx:yyyy:250:56ff:fe90:c6c3 type=129 code=0 id=28358 mark=0 use=2 conntrack v0.9.14 (conntrack-tools): 1 flow entries have been shown.
Regards
I can't find that command. The router web interface has tracked connections but again it's only listing v4 ones at the moment (a constant IPv6 ping is running from command line on this PC). First few lines....
Proto NATed Address Destination Address State tcp 192.168.1.63:55065 31.13.90.1:443 ASSURED tcp 192.168.1.150:62429 46.19.168.101:443 ASSURED tcp 192.168.1.150:62430 46.19.168.101:443 ASSURED tcp 192.168.1.150:59908 178.250.0.71:443 ESTABLISHED tcp 192.168.1.150:59608 40.77.229.13:443 ESTABLISHED tcp 192.168.1.162:50363 17.252.60.8:5223 ESTABLISHED tcp 192.168.1.198:45722 15.72.162.52:5222 ESTABLISHED
I just noticed the command line for the ping has a mix of timeouts and unreachables.
C:\WINDOWS\system32>ping -6 fe80::ea4:2ff:fe3e:1 -t Pinging fe80::ea4:2ff:fe3e:1 with 32 bytes of data: Destination host unreachable. Destination host unreachable. Request timed out. Request timed out. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Ping statistics for fe80::ea4:2ff:fe3e:1: Packets: Sent = 10, Received = 0, Lost = 10 (100% loss), Control-C ^C C:\WINDOWS\system32>
Is that significant?
And just realised that the Network Tools in the web interface has NetStat and it looks at v4 and v6, unlike the ping and trace route which are ipv4 only.
Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:5473 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:18017 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:3394 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:515 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:1990 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:139 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:9100 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:9998 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:80 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:80 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:53 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:22 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:23 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:8443 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:8443 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:39101 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:445 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:3838 0.0.0.0:* LISTEN tcp 0 0 192.168.1.1:80 192.168.1.150:62950 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62896 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62946 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62944 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62921 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62951 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62922 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62945 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62932 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62926 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62948 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62924 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62899 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62925 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62906 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62895 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62917 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62942 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62908 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62939 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62952 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62941 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62918 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62931 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62919 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62947 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62914 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62911 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62938 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62909 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62934 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62912 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62911 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62938 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62909 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62934 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62912 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62930 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62910 TIME_WAIT tcp 655 0 192.168.1.1:80 192.168.1.150:62956 ESTABLISHED tcp 0 0 192.168.1.1:80 192.168.1.150:62928 TIME_WAIT tcp 655 0 192.168.1.1:80 192.168.1.150:62954 ESTABLISHED tcp 0 0 192.168.1.1:80 192.168.1.150:62898 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62933 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62907 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62916 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62915 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62943 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62902 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62953 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62905 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62935 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62923 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62900 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62901 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62904 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62937 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62936 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62929 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62949 TIME_WAIT tcp 654 0 192.168.1.1:80 192.168.1.150:62957 ESTABLISHED tcp 0 0 192.168.1.1:80 192.168.1.150:62903 TIME_WAIT tcp 0 0 192.168.1.1:80 192.168.1.150:62920 TIME_WAIT tcp 0 0 ::1:139 :::* LISTEN tcp 0 0 fe80::a60:6eff:fecc:1ff0:139 :::* LISTEN tcp 0 0 2a00:23c5:7604:4200::1:53 :::* LISTEN tcp 0 0 ::1:53 :::* LISTEN tcp 0 0 fe80::a60:6eff:fecc:1ff0:53 :::* LISTEN tcp 0 0 ::1:445 :::* LISTEN tcp 0 0 fe80::a60:6eff:fecc:1ff0:445 :::* LISTEN udp 0 0 0.0.0.0:37000 0.0.0.0:* udp 0 0 192.168.1.255:137 0.0.0.0:* udp 0 0 192.168.1.1:137 0.0.0.0:* udp 0 0 0.0.0.0:137 0.0.0.0:* udp 0 0 192.168.1.255:138 0.0.0.0:* udp 0 0 192.168.1.1:138 0.0.0.0:* udp 0 0 0.0.0.0:138 0.0.0.0:* udp 0 0 0.0.0.0:9999 0.0.0.0:* udp 0 0 127.0.0.1:38032 0.0.0.0:* udp 0 0 0.0.0.0:42000 0.0.0.0:* udp 0 0 0.0.0.0:56230 0.0.0.0:* udp 0 0 127.0.0.1:42032 0.0.0.0:* udp 0 0 127.0.0.1:40500 0.0.0.0:* udp 0 0 127.0.0.1:53 0.0.0.0:* udp 0 0 192.168.1.1:53 0.0.0.0:* udp 0 0 0.0.0.0:67 0.0.0.0:* udp 0 0 127.0.0.1:37064 0.0.0.0:* udp 0 0 192.168.1.1:47822 0.0.0.0:* udp 0 0 0.0.0.0:5474 0.0.0.0:* udp 0 0 0.0.0.0:18018 0.0.0.0:* udp 0 0 192.168.1.1:5351 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:5353 0.0.0.0:* udp 0 0 0.0.0.0:1900 0.0.0.0:* udp 0 0 0.0.0.0:1900 0.0.0.0:* udp 0 0 0.0.0.0:38000 0.0.0.0:* udp 0 0 0.0.0.0:43000 0.0.0.0:* udp 0 0 0.0.0.0:59000 0.0.0.0:* udp 0 0 :::546 :::* udp 0 0 :::547 :::* udp 0 0 2a00:23c5:7604:4200::1:53 :::* udp 0 0 ::1:53 :::* udp 0 0 fe80::a60:6eff:fecc:1ff0:53 :::* raw 11440 0 :::58 :::* 58 raw 0 0 :::58 :::* 58 Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 2 [ ACC ] STREAM LISTENING 1819 /var/nmbd/unexpected unix 2 [ ACC ] STREAM LISTENING 1451 /etc/ProtectSrv_socket unix 6 [ ] DGRAM 3804 /dev/log unix 2 [ ] DGRAM 38314 unix 2 [ ] DGRAM 3953 unix 2 [ ] DGRAM 3806 unix 2 [ ] DGRAM 1965 unix 2 [ ] DGRAM 1651 unix 2 [ ] DGRAM 1632
@De_Carabas wrote:I just noticed the command line for the ping has a mix of timeouts and unreachables.
C:\WINDOWS\system32>ping -6 fe80::ea4:2ff:fe3e:1 -t Pinging fe80::ea4:2ff:fe3e:1 with 32 bytes of data: Destination host unreachable. Destination host unreachable. Request timed out. Request timed out. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Ping statistics for fe80::ea4:2ff:fe3e:1: Packets: Sent = 10, Received = 0, Lost = 10 (100% loss), Control-C ^C C:\WINDOWS\system32>Is that significant?
I'd expect no loss for this test as here you are pinging the link local address of the Asus router.
EDIT 1: Scrub that. I'd expect 100% loss as the address you're trying to ping is the BT upstream router link local address. This can only be ping'ed from the router.
EDIT 2: Leaving the rest in case it's useful to anyone.
Typically when pinging link local you should specify the interface to be used. To find out out the interface run the command route -6 print, after the 'IPv6 Route Table' note the number in the 'If' (interface) column and append this to the ping. For example:
C:\Users\smf22\>route -6 print =========================================================================== Interface List 6...00 21 cc 6d 2b 49 ......Intel(R) 82579LM Gigabit Network Connection [snip] =========================================================================== IPv6 Route Table =========================================================================== Active Routes: If Metric Network Destination Gateway 6 281 ::/0 fe80::46d9:e7ff:fe50:5b7e [snip] =========================================================================== Persistent Routes: None C:\Users\smf22>ping fe80::46d9:e7ff:fe50:5b7e%6 Pinging fe80::46d9:e7ff:fe50:5b7e with 32 bytes of data: Reply from fe80::46d9:e7ff:fe50:5b7e: time<1ms Reply from fe80::46d9:e7ff:fe50:5b7e: time<1ms Reply from fe80::46d9:e7ff:fe50:5b7e: time<1ms
Regards
Assuming I've done this right I see no difference. EDIT: Just seen the edit above and that it should fail
C:\WINDOWS\system32>route -6 print =========================================================================== Interface List 4...50 46 5d 53 0a 4b ......Realtek PCIe GBE Family Controller <snip> =========================================================================== IPv6 Route Table =========================================================================== Active Routes: If Metric Network Destination Gateway 4 281 ::/0 fe80::a60:6eff:fecc:1ff0 <snip> =========================================================================== Persistent Routes: None C:\WINDOWS\system32>ping -6 fe80::ea4:2ff:fe3e:1%4 Pinging fe80::ea4:2ff:fe3e:1%4 with 32 bytes of data: Destination host unreachable. Destination host unreachable. Destination host unreachable. Destination host unreachable. Ping statistics for fe80::ea4:2ff:fe3e:1%4: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
I started wondering if it could be an issue with my homeplug setup but then realised that wouldn't account for the inability to ping google from the router.
This really shouldn't be as hard as this. From the post ASUS RT-N66U router and ipv6 and specifically message 22 we know the configuration of the Asus RT-N66U that works with BT IPv6.
What we know with your setup and is good:
- Your router has IPv6 working and can ping the link local address of the upstream BT router
- It can successfully request an IPv6 prefix from the upstream router via DHCPv6
- It uses IPv6 Router Advertisement on the LAN interface to tell the clients the prefix it has been allocated
- The clients use stateless addressing to select an address from the advertised prefix
- They install a default IPv6 route to the link local address of the router
At this stage we don't know if IPv6 traffic is leaving your router. Based on the traceroute you posted earlier it seems traffic is not reaching your router either, but it could also simply be some hops on the path are not configured to respond.
I don't know how much more you want to get into this, but you could:
- install tcpdump on the Asus to capture IPv6 traffic in/out of the WAN interface; or
- connect the Asus to the modem via a switch with port mirroring and capture IPv6 traffic at that point
This would allow us to see whether IPv6 traffic from your LAN leaves the router, and using a public traceroute again, would show whether BT are routing the traffic for the prefix towards your router.
Regards
Did you do a 'factory reset' of the router after flashing the firmware? Even if you have it is worthwhile doing it now and manually enter the WAN settings and IPv6 settings rather than using any 'Quick Start' automatic configuration. The tests you have done seem to have covered all the bases making me still suspect the routers WAN configuration, as a hardware fault is unlikely at this stage.
If that seems to have made any difference you could try a ping on this IP-
2a00:23c3:63bb:7e01:35a0:d9d6:cee0:806f
It's a server and always on. It will reply if you have IPv6 working on your connection.