Tickets - Tunnel T13724 not working :: SixXS - IPv6 Deployment & Tunnel Broker

Ticket ID: SIXXS #824394
Ticket Status: User

PoP: deham01 - Easynet (Hamburg)

Tunnel T13724 not working

Shadow Hawkins on Sunday, 12 October 2008 22:08:48

Good evening, in the last weeks, my tunnel had some "hickups" which usually (automagically) resolved themselves after a couple of hours. Unfortunately, the latest "service outage" lasts... The symptoms resemble those in the forum thread Aiccu test 6/8 fails; no return traffic, but after reading the "Reporting Problems" section on the Contact page I considered a ticket the better choice - correct me if I'm wrong. I'm providing the following details for this report: Tunnel is T13724 (AYIYA), PoP is deham01, my handle is WPA1-SIXXS. I'm running aiccu in version 2007.01.15: - usually on an atheros-based embedded system running a compiled version for OpenWRT: Linux host 2.6.23.16 #2 Wed Feb 27 14:08:51 CET 2008 mips unknown - for testing and debugging purposes the Ubuntu package for amd64: Linux host 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux Both systems should have correct clocks, synched either via daily ntpdate or background ntpd. I am behind a NAT box. `aiccu test` fails at [6/8]:

Tunnel Information for T13724: POP Id : deham01 IPv6 Local : 2001:6f8:900:a84::2/64 IPv6 Remote : 2001:6f8:900:a84::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.178.102) [...] PING 192.168.178.102 (192.168.178.102) 56(84) bytes of data. 64 bytes from 192.168.178.102: icmp_seq=1 ttl=64 time=0.053 ms 64 bytes from 192.168.178.102: icmp_seq=2 ttl=64 time=0.048 ms 64 bytes from 192.168.178.102: icmp_seq=3 ttl=64 time=0.047 ms --- 192.168.178.102 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.047/0.049/0.053/0.006 ms ###### Did this work? [Y/n] ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (212.224.0.188) [...] PING 212.224.0.188 (212.224.0.188) 56(84) bytes of data. 64 bytes from 212.224.0.188: icmp_seq=1 ttl=55 time=34.0 ms 64 bytes from 212.224.0.188: icmp_seq=2 ttl=55 time=34.2 ms 64 bytes from 212.224.0.188: icmp_seq=3 ttl=55 time=33.4 ms --- 212.224.0.188 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 33.405/33.925/34.285/0.405 ms ###### Did this work? [Y/n] ####### [3/8] Traceroute to the PoP (212.224.0.188) over IPv4 [...] traceroute to 212.224.0.188 (212.224.0.188), 30 hops max, 40 byte packets 1 192.168.178.1 (192.168.178.1) 0.854 ms 1.203 ms 1.585 ms 2 * * * 3 ae1-211.ffm4-j2.mcbone.net (62.104.195.194) 24.221 ms 25.816 ms 27.024 ms 4 te0-0-0-5.er10.ixfra.de.easynet.net (80.81.192.14) 30.047 ms 30.707 ms 32.159 ms 5 te0-0-0.gr10.isham.de.easynet.net (87.86.77.65) 46.287 ms 46.932 ms 48.548 ms 6 ge3-7.br2.isham.de.easynet.net (87.86.71.241) 49.942 ms 32.794 ms 33.156 ms 7 ge7-1.cr20.isham.de.easynet.net (212.224.4.89) 34.670 ms 35.601 ms 37.739 ms 8 deham01.sixxs.net (212.224.0.188) 39.557 ms 39.794 ms 42.380 ms ###### Did this work? [Y/n] ###### [4/8] Checking if we can ping IPv6 localhost (::1) [...] PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.078 ms 64 bytes from ::1: icmp_seq=2 ttl=64 time=0.078 ms 64 bytes from ::1: icmp_seq=3 ttl=64 time=0.077 ms --- ::1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.077/0.077/0.078/0.010 ms ###### Did this work? [Y/n] ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:6f8:900:a84::2) [...] PING 2001:6f8:900:a84::2(2001:6f8:900:a84::2) 56 data bytes 64 bytes from 2001:6f8:900:a84::2: icmp_seq=1 ttl=64 time=0.081 ms 64 bytes from 2001:6f8:900:a84::2: icmp_seq=2 ttl=64 time=0.082 ms 64 bytes from 2001:6f8:900:a84::2: icmp_seq=3 ttl=64 time=0.089 ms --- 2001:6f8:900:a84::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.081/0.084/0.089/0.003 ms ###### Did this work? [Y/n] ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:6f8:900:a84::1) [...] PING 2001:6f8:900:a84::1(2001:6f8:900:a84::1) 56 data bytes --- 2001:6f8:900:a84::1 ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 2009ms ###### Did this work? [Y/n] n [...]

I flushed my local ip6tables to make sure that problem's not caused by firewalling.

root@host:/# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination

The output of tcpdump while ping6'ing the tunnel endpoint:

root@host:# tcpdump -i eth0 -nnv host 212.224.0.188 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes 21:45:29.276352 IP (tos 0x0, ttl 64, id 23122, offset 0, flags [DF], proto UDP (17), length 176) 192.168.178.102.33633 > 212.224.0.188.5072: UDP, length 148 21:45:30.284092 IP (tos 0x0, ttl 64, id 23123, offset 0, flags [DF], proto UDP (17), length 176) 192.168.178.102.33633 > 212.224.0.188.5072: UDP, length 148 21:45:31.286382 IP (tos 0x0, ttl 64, id 23124, offset 0, flags [DF], proto UDP (17), length 176) 192.168.178.102.33633 > 212.224.0.188.5072: UDP, length 148

my routing table:

root@host:/# route -n --inet6 Kernel IPv6 routing table Destination Next Hop Flag Met Ref Use If ::1/128 :: Un 0 1 62 lo 2001:6f8:900:a84::/128 :: Un 0 2 0 lo 2001:6f8:900:a84::2/128 :: Un 0 1 0 lo 2001:6f8:900:a84::/64 :: U 256 0 1 aiccu fe80::/128 :: Un 0 2 0 lo fe80::/128 :: Un 0 2 0 lo fe80::217:31ff:fec3:2eb7/128 :: Un 0 1 19 lo fe80::4f8:900:a84:2/128 :: Un 0 1 0 lo fe80::/64 :: U 256 0 0 eth0 fe80::/64 :: U 256 0 0 aiccu ff00::/8 :: U 256 0 0 eth0 ff00::/8 :: U 256 0 0 aiccu ::/0 2001:6f8:900:a84::1 UG 1024 0 10 aiccu ::/0 :: !n -1 1 114 lo

Information about the aiccu device:

root@host:/# ifconfig aiccu aiccu Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet6 addr: 2001:6f8:900:a84::2/64 Scope:Global inet6 addr: fe80::4f8:900:a84:2/64 Scope:Link UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:0 (0.0 B) TX bytes:1472 (1.4 KB)

Information about the Ethernet device:

root@host:/# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:17:31:c3:2e:b7 inet addr:192.168.178.102 Bcast:192.168.178.255 Mask:255.255.255.0 inet6 addr: fe80::217:31ff:fec3:2eb7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28915 errors:0 dropped:0 overruns:0 frame:0 TX packets:37217 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9076002 (8.6 MB) TX bytes:5642572 (5.3 MB) Interrupt:23 Base address:0x6000

I hope this doesn't reveal some basic misconfiguration on my part. Please let me know if I can provide any more information. Thanks in advance! Sincerely, Wolfgang Plappert

State change: user Locked

Jeroen Massar SixXS Staff

on Monday, 13 October 2008 11:32:56

The state of this ticket has been changed to user

Tunnel T13724 not working

Jeroen Massar SixXS Staff

on Monday, 13 October 2008 11:35:06

OpenWRT -> which version of the binary are you using, they are distributing a broken version of AICCU which does not work.

traceroute to 212.224.0.188 (212.224.0.188), 30 hops max, 40 byte packets

1 192.168.178.1 (192.168.178.1) 0.854 ms 1.203 ms 1.585 ms

2 * * *

3 ae1-211.ffm4-j2.mcbone.net (62.104.195.194) 24.221 ms 25.816 ms 27.024 ms

What host is dropping packets there? Also, what kind of NAT box are you using?

Tunnel T13724 not working

Shadow Hawkins on Monday, 13 October 2008 22:13:22

Hi, thanks for your quick reply, I appreciate your help. For the version of aiccu on the OpenWRT box:

root@host:~# aiccu version AICCU 2007.01.15-console by Jeroen Massar

which was obtained from the OpenWRT SVN as part of r11142 on May 15th 2008 and compiled from source - I hope that helps. As one can see from the latency statistics, there were valid replies from my end of the tunnel with that particular aiccu version. I haven't changed anything in the firmware or configuration. Unfortunately, the problems also occur with the named ubuntu-delivered amd64 version for "hardy heron" (which answers with the exact same version reply) which I used in tests after the other end of the tunnel didn't answer to my calls anymore. Looks like the responsible host that drops packets or doesn't feel obligated to answer to ICMP is L0.ffm4-lns4.mcbone.net - which is part of my ISP's infrastructure, and for some reason only answers once in a blue moon or so:

root@host:~$ traceroute deham01.sixxs.net traceroute to deham01.sixxs.net (212.224.0.188), 30 hops max, 38 byte packets 1 192.168.178.1 (192.168.178.1) 1.118 ms 1.142 ms 1.125 ms 2 L0.ffm4-lns4.mcbone.net (62.104.190.24) 19.692 ms * * 3 ae1-211.ffm4-j.mcbone.net (62.104.195.193) 18.819 ms 18.981 ms 19.166 ms 4 te0-0-0-5.er10.ixfra.de.easynet.net (80.81.192.14) 21.138 ms 21.177 ms 21.128 ms 5 te0-0-0.gr10.isham.de.easynet.net (87.86.77.65) 32.675 ms 33.946 ms 32.591 ms 6 ge3-7.br2.isham.de.easynet.net (87.86.71.241) 32.976 ms 34.660 ms 34.252 ms 7 ge7-1.cr20.isham.de.easynet.net (212.224.4.89) 32.844 ms 34.757 ms 33.886 ms 8 deham01.sixxs.net (212.224.0.188) 34.422 ms 33.968 ms 33.195 ms

The NAT box is a Samsung SMT-G3010 ADSL2+ "Router" with firmware V03.01 (21-07-2008). Though configuring that thing is pretty annoying, it should do its basic job - and the tunnel in fact did work already with that router between the box running aiccu and the outside world. Best regards, Wolfgang

Tunnel T13724 not working

Shadow Hawkins on Thursday, 16 October 2008 14:51:12

Hello, somehow, yesterday, packets started traveling through the tunnel again. I am absolutely clueless of what changed its mind, I on my part haven't changed anything - I didn't even reboot any of the involved devices. Unfortunately, it indeed appears to be a, how to put it... client-side problem. The only conclusive solution coming to mind is that the (useless piece of junk) routing box screws up the packet forwarding business. As there's no low level logging capability offered in the embedded device, I can only guess. I'm not sure about what to do the next time aiccu says the tunnel is up and running but doesn't transport packets, but on the long run, I will have to run tests with a different Modem/Router combination. I am sorry about having wasted your time. Best regards, Wolfgang PS: Does there, by any chance, exist a list of customer-premises DSL equipment that has proven to be problematic in cooperation with aiccu-based tunneling?

Tunnel T13724 not working

Jeroen Massar SixXS Staff

on Thursday, 16 October 2008 14:56:50

AICCU can't indicate in it's current edition that a tunnel is 'up and running'. The only way to test that a tunnel is working is: - being able to ping tunnel::2 - being able to ping tunnel::1 - being able to ping at least www.sixxs.net / ipv6.google.com etc Then doing at least something HTTP transfers to well known hosts is also important of course ;) We are working on extending AICCU to support a generic test mode (also for use without tunnels), unfortunately time is limited.

Please note Posting is only allowed when you are logged in.