Forum - Ping tunnel endpoint test fails :: SixXS - IPv6 Deployment & Tunnel Broker

Ping tunnel endpoint test fails

Shadow Hawkins on Monday, 13 August 2012 11:59:59

I have setup my computer for a Sixxs tunnel and all in all it works I can ping as well as access with a browser IPv6 addresses and domains. Nevertheless, doing the AICCU test I get 100% packet loss for test 5 (all the other test results are alright): ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:15c0:65ff:6c7::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING6(56=40+8+8 bytes) 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::2 I do not understand how I could either test for the reasons as described in the FAQ, nor how to solve the issue e.g. how do I know if I am blocking ICMPv6? And if I do, how would I unblock ICMPv6? Cheers, Tobi -- Setup: Mac OS X 10.7.4 using AICCU NIC handle: TSB9-SIXXS Tunnel: T101122 $ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 inet6 fd40:cc28:ceec:b128:21e:c2ff:fe14:1a1a prefixlen 128 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4> ether 00:1e:c2:14:1a:1a media: autoselect status: inactive en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:1e:c2:a4:3a:dc inet 192.168.0.130 netmask 0xffffff00 broadcast 192.168.0.255 media: autoselect status: active fw0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030 lladdr 00:1f:5b:ff:fe:1c:05:4a media: autoselect <full-duplex> status: inactive utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380 inet6 fe80::21e:c2ff:fe14:1a1a%utun0 prefixlen 64 scopeid 0x7 inet6 fd00:6587:52d7:855:21e:c2ff:fe14:1a1a prefixlen 64 tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1280 inet6 fe80::21e:c2ff:fe14:1a1a%tun0 prefixlen 64 scopeid 0x8 inet6 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::1 prefixlen 128 open (pid 26058) $ netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGSc 48 18 en1 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 5 9941 lo0 169.254 link#5 UCS 0 0 en1 192.168.0 link#5 UCS 5 0 en1 192.168.0.1 64:87:d7:b1:9d:91 UHLWIi 60 10670 en1 1192 192.168.0.130 127.0.0.1 UHS 0 15 lo0 192.168.0.131 58:55:ca:a0:ca:d1 UHLWIi 7 14399 en1 568 192.168.0.133 0:1e:52:86:ce:a UHLWIi 0 1 en1 192.168.0.135 0:1c:b3:b2:51:ae UHLWIi 6 370 en1 1181 192.168.0.255 ff:ff:ff:ff:ff:ff UHLWbI 0 4 en1 Internet6: Destination Gateway Flags Netif Expire default 2001:15c0:65ff:6c7::1 UGSc tun0 ::1 link#1 UHL lo0 2001:15c0:65ff:6c7::1 2001:15c0:65ff:6c7::2 UH tun0 2001:15c0:65ff:6c7::2 link#8 UHL lo0 fd00:6587:52d7::/48 fd00:6587:52d7:855:21e:c2ff:fe14:1a1a UGCS utun0 fd00:6587:52d7:855::/64 fe80::21e:c2ff:fe14:1a1a%utun0 Uc utun0 fd00:6587:52d7:855:21e:c2ff:fe14:1a1a link#7 UHL lo0 fd40:cc28:ceec:b128:21e:c2ff:fe14:1a1a link#1 UHL lo0 fe80::%lo0/64 fe80::1%lo0 UcI lo0 fe80::1%lo0 link#1 UHLI lo0 fe80::%utun0/64 fe80::21e:c2ff:fe14:1a1a%utun0 UcI utun0 fe80::21e:c2ff:fe14:1a1a%utun0 link#7 UHLI lo0 fe80::%tun0/64 fe80::21e:c2ff:fe14:1a1a%tun0 UcI tun0 fe80::21e:c2ff:fe14:1a1a%tun0 link#8 UHLI lo0 ff01::%lo0/32 fe80::1%lo0 UmCI lo0 ff01::%utun0/32 fe80::21e:c2ff:fe14:1a1a%utun0 UmCI utun0 ff01::%tun0/32 fe80::21e:c2ff:fe14:1a1a%tun0 UmCI tun0 ff02::%lo0/32 fe80::1%lo0 UmCI lo0 ff02::%utun0/32 fe80::21e:c2ff:fe14:1a1a%utun0 UmCI utun0 ff02::%tun0/32 fe80::21e:c2ff:fe14:1a1a%tun0 UmCI tun0

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Monday, 13 August 2012 15:22:09

I do not understand how I could either test for the reasons as described in the FAQ

It has no direct relation to anything mentioned in the FAQ. The test mentioned in the FAQ is a ICMPv6 response test from the PoP to your endpoint. The problem shown above is that your own computer can't ping your own computer.

, nor how to solve the issue e.g. how do I know if I am blocking ICMPv6?

Check your firewall rules, check your logs, try traceroutes etc etc etc.

inet6 fd00:6587:52d7:855:21e:c2ff:fe14:1a1a prefixlen 64

What is this address doing there? That looks like an address in the ULA range, but it cannot be in the ULA range as it not even remotely looks random to comply to it. It also seems you have a 'tun0' and a 'utun0' which is which and what do they do? The utun0 has the same link-local as the tun0, while that might work, it is likely not something that is correct.

inet6 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::1 prefixlen 128

That at least shows that the interface is configured. Check if you have any special firewalling software enabled and/or the Mac firewalling software is configured to block anything. Logs are a great thing to check.

Ping tunnel endpoint test fails

Shadow Hawkins on Tuesday, 14 August 2012 23:12:22

I disabled the OS X firewall and ran the tests again with the same result, all tests succeeding except #5. Here is a traceroute6 from another IPv6 enabled machine [1].

inet6 fd00:6587:52d7:855:21e:c2ff:fe14:1a1a prefixlen 64

What is this address doing there? That looks like an address in the ULA range, but it cannot be in the ULA range as it not even remotely looks random to comply to it.

To be honest: I do not have any clue where that address is coming from. Neither do I know what an ULA range is. Same with the utun0 interface: I did not install this by myself, resp. do not know of a software package that could have installed it. Is it an Apple thing [2]? How can I find this out? Can I get rid of it? If yes, how? I also tried adding the IPv6 of my local (2001:15c0:65ff:6c7::2) and the remote (2001:15c0:65ff:6c7::1) endpoint as manual IPv6 configuration in the Network:Advanced:TCP/IP panel of System Preferences. Is this correct / necessary? Afterwards test #5 succeeded but unfortunately, test #7 failed [3]. Further help is appreciated. Cheers, Tobi -- [1]

# traceroute6 2001:15c0:65ff:6c7::2 traceroute to 2001:15c0:65ff:6c7::2 (2001:15c0:65ff:6c7::2) from 2a01:4f8:a0:2161::2, 30 hops max, 24 byte packets 1 2a01:4f8:a0:2160::1 (2a01:4f8:a0:2160::1) 5.178 ms 1.557 ms 0.683 ms 2 2a01:4f8:0:a:3:0:a:2 (2a01:4f8:0:a:3:0:a:2) 0.355 ms 0.366 ms 0.25 ms 3 2a01:4f8:0:2::1:4 (2a01:4f8:0:2::1:4) 3.302 ms 3.298 ms 3.273 ms 4 frankfurt1-ge-1-13-2004.amis.net (2001:7f8::218f:0:1) 24.818 ms 24.311 ms 24.347 ms 5 maribor3-te-1-3.amis.net (2001:15c0:ffff:d::2) 27.62 ms 32.583 ms 27.797 ms 6 maribor3-te-7-4.amis.net (2001:15c0:ffff:d::d) 28.483 ms 27.762 ms 27.671 ms 7 2001:15c0:ffff:7:250:56ff:feaa:2 (2001:15c0:ffff:7:250:56ff:feaa:2) 27.782 ms 27.911 ms 27.936 ms 8 gw-1736.mbx-01.si.sixxs.net (2001:15c0:65ff:6c7::1) 28.489 ms 28.228 ms 28.118 ms 9 * * * 10 * gw-1736.mbx-01.si.sixxs.net (2001:15c0:65ff:6c7::1) 28.055 ms !N 27.846 ms !N

[2] In the kernel.log I found

14.08.12 20:39:02,000 kernel: utun_ctl_connect: creating interface utun0

and I found the file if_utun.h in /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/net/ on my machine and via Google at if_utun.h [3]

###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net) ### This confirms that you can reach the central machine of SixXS ### If that one is reachable you should be able to reach most IPv6 destinations ### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection ### If your browser supports IPv6 and uses it of course. traceroute6 to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:15c0:65ff:6c7::2, 64 hops max, 12 byte packets sendto: No buffer space available 1 traceroute6: wrote noc.sixxs.net 12 chars, ret=-1 *sendto: No buffer space available traceroute6: wrote noc.sixxs.net 12 chars, ret=-1 etc. etc.

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Tuesday, 14 August 2012 23:11:36

I disabled the OS X firewall and ran the tests again with the same result, all tests succeeding except #5.

Does disabling it cause packets to be rejected or to be accepted per default? Also, is maybe something like Little Snitch active?

I also tried adding the IPv6 of my local (2001:15c0:65ff:6c7::2) and the remote (2001:15c0:65ff:6c7::1) endpoint as manual IPv6 configuration in the Network:Advanced:TCP/IP panel of System Preferences. Is this correct / necessary?

That is wrong and not needed.

Ping tunnel endpoint test fails

Shadow Hawkins on Tuesday, 14 August 2012 23:32:20

Does disabling it cause packets to be rejected or to be accepted per default?

AFAIK, disabling cause packets to be accepted per default.

Also, is maybe something like Little Snitch active?

No little snitch, no other packet filter I know of.

Ping tunnel endpoint test fails

Shadow Hawkins on Tuesday, 14 August 2012 23:13:01

Bummer, somehow the last part of my previous post got corrupted, so here it is again: [1]

[2] In the kernel.log I found

14.08.12 20:39:02,000 kernel: utun_ctl_connect: creating interface utun0

and I found the file if_utun.h in /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/net/ on my machine and via Google at if_utun.h [3]

Ping tunnel endpoint test fails

Shadow Hawkins on Tuesday, 14 August 2012 21:22:20

Well, this forum software is fun :-/ (Can I delete the previous post somehow?) One more try: [1]

[2] In the kernel.log I found

14.08.12 20:39:02,000 kernel: utun_ctl_connect: creating interface utun0

and I found the file if_utun.h in /System/Library/Frameworks/Kernel.framework/Versions/A/Headers/net/ on my machine and via Google at http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/net/if_utun.h [3]

Ping tunnel endpoint test fails

Shadow Hawkins on Tuesday, 14 August 2012 23:04:16

I now found out where the utun0 interface is coming from: it is created by Apples Back to My Mac service (under Preferences:iCloud). After I disabled it, my ifconfig output now looks like this:

$ ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 inet6 ::1 prefixlen 128 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4> ether 00:1e:c2:14:1a:1a media: autoselect status: inactive en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:1e:c2:a4:3a:dc inet6 fe80::21e:c2ff:fea4:3adc%en1 prefixlen 64 scopeid 0x5 inet 192.168.0.130 netmask 0xffffff00 broadcast 192.168.0.255 media: autoselect status: active fw0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 2030 lladdr 00:1f:5b:ff:fe:1c:05:4a media: autoselect <full-duplex> status: inactive tun0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1280 inet6 fe80::21e:c2ff:fe14:1a1a%tun0 prefixlen 64 scopeid 0x8 inet6 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::1 prefixlen 128 open (pid 5064)

But still test #5 is failing and still no idea where inet6 fe80::21e:c2ff:fea4:3adc%en1 prefixlen 64 scopeid 0x5 is coming from

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Tuesday, 14 August 2012 23:15:14

But still test #5 is failing

If you are unable to reach the local side of your tunnel, nothing much else should in theory work as then your address is not even properly assigned it seems.

and still no idea where inet6 fe80::21e:c2ff:fea4:3adc%en1 prefixlen 64 scopeid 0x5 is coming from

That is a link-local address (fe80::/10), that always exists on IPv6 enabled interfaces.

Ping tunnel endpoint test fails

Shadow Hawkins on Tuesday, 14 August 2012 23:26:53

If you are unable to reach the local side of your tunnel, nothing much else should in theory work as then your address is not even properly assigned it seems.

Well, then practice beats theory see the traceroute6 in one of the previous posts. So if I get this right, I can reach the local endpoint from another machine but not from the endpoint itself?

remote$ ping6 -c3 2001:15c0:65ff:6c7::2 PING 2001:15c0:65ff:6c7::2(2001:15c0:65ff:6c7::2) 56 data bytes 64 bytes from 2001:15c0:65ff:6c7::2: icmp_seq=1 ttl=53 time=51.1 ms 64 bytes from 2001:15c0:65ff:6c7::2: icmp_seq=2 ttl=53 time=315 ms 64 bytes from 2001:15c0:65ff:6c7::2: icmp_seq=3 ttl=53 time=233 ms --- 2001:15c0:65ff:6c7::2 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2001ms rtt min/avg/max/mdev = 51.168/200.077/315.276/110.425 ms local$ sudo aiccu autotest Tunnel Information for T101122: POP Id : simbx01 IPv6 Local : 2001:15c0:65ff:6c7::2/64 IPv6 Remote : 2001:15c0:65ff:6c7::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled add net default: gateway 2001:15c0:65ff:6c7::1 ####### ####### AICCU Quick Connectivity Test ####### ####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.0.130) ### This should return so called 'echo replies' ### If it doesn't then check your firewall settings ### Your local endpoint should always be pingable ### It could also indicate problems with your IPv4 stack PING 192.168.0.130 (192.168.0.130): 56 data bytes 64 bytes from 192.168.0.130: icmp_seq=0 ttl=64 time=0.064 ms 64 bytes from 192.168.0.130: icmp_seq=1 ttl=64 time=0.071 ms 64 bytes from 192.168.0.130: icmp_seq=2 ttl=64 time=0.074 ms --- 192.168.0.130 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.064/0.070/0.074/0.004 ms ###### ####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (212.18.63.73) ### These pings should reach the PoP and come back to you ### In case there are problems along the route between your ### host and the PoP this could not return replies ### Check your firewall settings if problems occur PING 212.18.63.73 (212.18.63.73): 56 data bytes 64 bytes from 212.18.63.73: icmp_seq=0 ttl=54 time=47.751 ms 64 bytes from 212.18.63.73: icmp_seq=1 ttl=54 time=22.077 ms 64 bytes from 212.18.63.73: icmp_seq=2 ttl=54 time=31.762 ms --- 212.18.63.73 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 22.077/33.863/47.751/10.586 ms ###### ####### [3/8] Traceroute to the PoP (212.18.63.73) over IPv4 ### This traceroute should reach the PoP ### In case this traceroute fails then you have no connectivity ### to the PoP and this is most probably the problem traceroute to 212.18.63.73 (212.18.63.73), 64 hops max, 52 byte packets 1 silverserverdsl (192.168.0.1) 11.453 ms 13.675 ms 0.740 ms 2 vie-188-118-240-000.dsl.sil.at (188.118.240.0) 17.665 ms 15.411 ms 16.532 ms 3 gi2-10.c2.oe3.sil.at (86.59.116.117) 18.710 ms simbx01.sixxs.net (212.18.63.73) 1.190 ms 1.083 ms ###### ###### [4/8] Checking if we can ping IPv6 localhost (::1) ### This confirms if your IPv6 is working ### If ::1 doesn't reply then something is wrong with your IPv6 stack PING6(56=40+8+8 bytes) ::1 --> ::1 16 bytes from ::1: Echo Request 16 bytes from ::1, icmp_seq=0 hlim=64 dst=::1 time=0.158 ms 16 bytes from ::1: Echo Request 16 bytes from ::1, icmp_seq=1 hlim=64 dst=::1 time=0.175 ms 16 bytes from ::1: Echo Request 16 bytes from ::1, icmp_seq=2 hlim=64 dst=::1 time=0.275 ms --- ::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.158/0.203/0.275/0.052 ms ###### ###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:15c0:65ff:6c7::2) ### This confirms that your tunnel is configured ### If it doesn't reply then check your interface and routing tables PING6(56=40+8+8 bytes) 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::2 --- 2001:15c0:65ff:6c7::2 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss ###### ###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:15c0:65ff:6c7::1) ### This confirms the reachability of the other side of the tunnel ### If it doesn't reply then check your interface and routing tables ### Don't forget to check your firewall of course ### If the previous test was succesful then this could be both ### a firewalling and a routing/interface problem PING6(56=40+8+8 bytes) 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::1 16 bytes from 2001:15c0:65ff:6c7::1, icmp_seq=0 hlim=64 dst=2001:15c0:65ff:6c7::2 time=22.855 ms 16 bytes from 2001:15c0:65ff:6c7::1, icmp_seq=1 hlim=64 dst=2001:15c0:65ff:6c7::2 time=28.976 ms 16 bytes from 2001:15c0:65ff:6c7::1, icmp_seq=2 hlim=64 dst=2001:15c0:65ff:6c7::2 time=28.538 ms --- 2001:15c0:65ff:6c7::1 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 22.855/26.790/28.976/2.788 ms ###### ###### [7/8] Traceroute6 to the central SixXS machine (noc.sixxs.net) ### This confirms that you can reach the central machine of SixXS ### If that one is reachable you should be able to reach most IPv6 destinations ### Also check http://www.sixxs.net/ipv6calc/ which should show an IPv6 connection ### If your browser supports IPv6 and uses it of course. traceroute6 to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c) from 2001:15c0:65ff:6c7::2, 64 hops max, 12 byte packets 1 gw-1736.mbx-01.si.sixxs.net 26.822 ms 22.995 ms 23.076 ms 2 2001:15c0:ffff:7:250:56ff:feaa:2 23.317 ms 24.842 ms 22.523 ms 3 maribor3-vlan-4.amis.net 22.297 ms 25.607 ms 43.952 ms 4 mx-mb1-te-1-3-1.amis.net 56.027 ms 25.316 ms 23.288 ms 5 mx-vi1-te-0-0-1.amis.net 28.730 ms 30.588 ms 57.504 ms 6 cisco-f-iii-gi1-1.space.net 44.270 ms 44.344 ms 44.151 ms 7 cisco-m-xxxi-te5-5.space.net 49.082 ms 49.862 ms 49.986 ms 8 ge-1-1-0-zcr1.muc.cw.net 49.924 ms 49.130 ms 48.698 ms 9 xe-10-2-0-xcr1.fra.cw.net 58.674 ms 67.045 ms 114.469 ms 10 xe-1-0-1-xcr1.amd.cw.net 64.948 ms xe-1-1-1-xcr1.amd.cw.net 84.270 ms 65.928 ms 11 xe-11-1-0-xcr1.amt.cw.net 68.442 ms xe-5-1-0-xcr1.amt.cw.net 64.017 ms 75.810 ms 12 ams-ix.ipv6.concepts.nl 56.595 ms 56.433 ms 56.662 ms 13 2001:838:5:a::2 59.980 ms 59.180 ms 58.856 ms 14 noc.sixxs.net 60.079 ms 57.990 ms 59.509 ms ###### ###### [8/8] Traceroute6 to (www.kame.net) ### This confirms that you can reach a Japanese IPv6 destination ### If that one is reachable you should be able to reach most IPv6 destinations ### You should also check http://www.kame.net which should display ### a animated kame (turtle), of course only when your browser supports and uses IPv6 traceroute6 to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2001:15c0:65ff:6c7::2, 64 hops max, 12 byte packets 1 gw-1736.mbx-01.si.sixxs.net 24.268 ms 28.336 ms 24.946 ms 2 2001:15c0:ffff:7:250:56ff:feaa:2 21.781 ms 23.971 ms 27.482 ms 3 maribor3-vlan-4.amis.net 24.195 ms 24.585 ms 32.260 ms 4 mx-mb1-te-1-3-1.amis.net 23.314 ms 22.243 ms 24.272 ms 5 mx-vi1-te-0-0-1.amis.net 25.615 ms 28.333 ms 25.220 ms 6 win-b4-link.telia.net 26.932 ms 30.779 ms 29.642 ms 7 ldn-b5-v6.telia.net 63.548 ms 58.754 ms 59.571 ms 8 verio-ic-129583-ldn-b5.c.telia.net 75.067 ms 59.004 ms 60.033 ms 9 ae-4.r23.londen03.uk.bb.gin.ntt.net 57.221 ms 59.875 ms 59.660 ms 10 as-0.r22.osakjp01.jp.bb.gin.ntt.net 608.172 ms 579.531 ms 314.553 ms 11 ae-5.r24.tokyjp01.jp.bb.gin.ntt.net 324.238 ms 414.408 ms 383.691 ms 12 po-1.a15.tokyjp01.jp.ra.gin.ntt.net 676.130 ms 544.283 ms 657.088 ms 13 ge-8-2.a15.tokyjp01.jp.ce.gin.ntt.net 609.136 ms 549.989 ms 317.023 ms 14 ve44.foundry6.otemachi.wide.ad.jp 469.389 ms 433.253 ms 614.242 ms 15 ve42.foundry4.nezu.wide.ad.jp 457.641 ms 609.706 ms 616.136 ms 16 cloud-net1.wide.ad.jp 612.436 msp 604.605 msing 612.525 ms ^R 17 2001:200:dff:fff1:216:3eff:feb1:44d7 615.864 ms 610.361 ms 619.661 ms ###### ###### ACCU Quick Connectivity Test (done)

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Wednesday, 15 August 2012 13:35:43

So if I get this right, I can reach the local endpoint from another machine but not from the endpoint itself?

That is what it is looking like. Which can only mean you have some kind of filtering happening somewhere, or another misconfiguration. You might want to try tcpdumping the loopback interface an check what happens to your pings there and separately tcpdump the tunnel interface to see if it maybe ends up there or not.

Interesting that your latency jumps from 51ms to well over 200ms...

traceroute6 to orange.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7) from 2001:15c0:65ff:6c7::2, 64 hops max, 12 byte packets

There it also seems to use the right source addresss.

Ping tunnel endpoint test fails

Shadow Hawkins on Wednesday, 15 August 2012 14:10:26

OK, below are the tcpdump outputs (are those the right ones?) created by this ping6 command: $ ping6 -c3 2001:15c0:65ff:6c7::2 PING6(56=40+8+8 bytes) 2001:15c0:65ff:6c7::2 --> 2001:15c0:65ff:6c7::2 --- 2001:15c0:65ff:6c7::2 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss $ sudo tcpdump -vvv -i tun0 tcpdump: WARNING: tun0: no IPv4 address assigned tcpdump: listening on tun0, link-type NULL (BSD loopback), capture size 65535 bytes 14:08:25.741462 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 988) gw-1736.mbx-01.si.sixxs.net > cl-1736.mbx-01.si.sixxs.net: [icmp6 sum ok] ICMP6, echo request, length 988, seq 3227 14:08:25.741520 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 988) cl-1736.mbx-01.si.sixxs.net > gw-1736.mbx-01.si.sixxs.net: [icmp6 sum ok] ICMP6, echo reply, length 988, seq 3227 14:08:27.728371 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) cl-1736.mbx-01.si.sixxs.net > cl-1736.mbx-01.si.sixxs.net: [icmp6 sum ok] ICMP6, echo request, length 16, seq 0 14:08:28.728493 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) cl-1736.mbx-01.si.sixxs.net > cl-1736.mbx-01.si.sixxs.net: [icmp6 sum ok] ICMP6, echo request, length 16, seq 1 14:08:29.729293 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 16) cl-1736.mbx-01.si.sixxs.net > cl-1736.mbx-01.si.sixxs.net: [icmp6 sum ok] ICMP6, echo request, length 16, seq 2 ^C 5 packets captured 5 packets received by filter 0 packets dropped by kernel $ sudo tcpdump -vvv -i lo0 tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 65535 bytes 14:08:26.418591 IP (tos 0x0, ttl 255, id 60454, offset 0, flags [none], proto UDP (17), length 89) macke.local.mdns > 224.0.0.251.mdns: [udp sum ok] 0 [2q] SRV (QM)? Brother DCP-585CW._printer._tcp.local. TXT (QM)? Brother DCP-585CW._printer._tcp.local. (61) 14:08:26.418760 IP6 (hlim 255, next-header UDP (17) payload length: 69) macke.local.mdns > ff02::fb.mdns: [udp sum ok] 0 [2q] SRV (QM)? Brother DCP-585CW._printer._tcp.local. TXT (QM)? Brother DCP-585CW._printer._tcp.local. (61) 14:08:26.621924 IP (tos 0x0, ttl 255, id 30004, offset 0, flags [none], proto UDP (17), length 118) macke.local.mdns > 224.0.0.251.mdns: [udp sum ok] 0 PTR (QM)? c.d.a.3.4.a.e.f.f.f.2.c.e.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90) 14:08:26.622076 IP6 (hlim 255, next-header UDP (17) payload length: 98) macke.local.mdns > ff02::fb.mdns: [udp sum ok] 0 PTR (QM)? c.d.a.3.4.a.e.f.f.f.2.c.e.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. (90) 14:08:26.722379 IP (tos 0x0, ttl 255, id 23135, offset 0, flags [none], proto UDP (17), length 155) macke.local.mdns > 224.0.0.251.mdns: [udp sum ok] 0*- [0q] 1/0/1 C.D.A.3.4.A.E.F.F.F.2.C.E.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) [2m] PTR macke.local. ar: C.D.A.3.4.A.E.F.F.F.2.C.E.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) [2m] NSEC (127) 14:08:26.722470 IP6 (hlim 255, next-header UDP (17) payload length: 135) macke.local.mdns > ff02::fb.mdns: [udp sum ok] 0*- [0q] 1/0/1 C.D.A.3.4.A.E.F.F.F.2.C.E.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) [2m] PTR macke.local. ar: C.D.A.3.4.A.E.F.F.F.2.C.E.1.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.E.F.ip6.arpa. (Cache flush) [2m] NSEC (127) 14:08:27.422103 IP (tos 0x0, ttl 255, id 25112, offset 0, flags [none], proto UDP (17), length 89) macke.local.mdns > 224.0.0.251.mdns: [udp sum ok] 0 [2q] SRV (QM)? Brother DCP-585CW._printer._tcp.local. TXT (QM)? Brother DCP-585CW._printer._tcp.local. (61) 14:08:27.422366 IP6 (hlim 255, next-header UDP (17) payload length: 69) macke.local.mdns > ff02::fb.mdns: [udp sum ok] 0 [2q] SRV (QM)? Brother DCP-585CW._printer._tcp.local. TXT (QM)? Brother DCP-585CW._printer._tcp.local. (61) ^C 8 packets captured 8 packets received by filter 0 packets dropped by kernel

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Wednesday, 15 August 2012 17:56:18

OK, below are the tcpdump outputs (are those the right ones?) created by this ping6 command:

Normally traffic from + to addresses that live on the local host are visible on loopback and responds to ICMP. But it seems Apple broke something in Mountain Lion, as on my own box:

jeroen@mountain:~$ ping6 2001:db8:ff00::aaaa:aaff:feaa:bbbb PING6(56=40+8+8 bytes) 2001:db8:ff00::aaaa:aaff:feaa:bbbb --> 2001:db8:ff00::aaaa:aaff:feaa:bbbb ^C --- 2001:db8:ff00::aaaa:aaff:feaa:bbbb ping6 statistics --- 5 packets transmitted, 0 packets received, 100.0% packet loss jeroen@mountain:~$ uname -a Darwin mountain.ch.unfix.org 12.0.0 Darwin Kernel Version 12.0.0: Sun Jun 24 23:00:16 PDT 2012; root:xnu-2050.7.9~1/RELEASE_X86_64 x86_64

And that is an address on a real ethernet interface that also works. But on a Snow Leopard box:

jeroen@snow$ ping6 2001:db8:ff00::aaaa:aaff:feaa:aaaa PING6(56=40+8+8 bytes) 2001:db8:ff00::aaaa:aaff:feaa:aaaa --> 2001:db8:ff00::aaaa:aaff:feaa:aaaa 16 bytes from 2001:db8:ff00::aaaa:aaff:feaa:aaaa, icmp_seq=0 hlim=64 time=0.071 ms ^C --- 2001:db8:ff00::aaaa:aaff:feaa:aaaa ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.071/0.071/0.071/0.000 ms jeroen@snow$ uname -a Darwin snow 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386

it works.... think we have a kernel regression here or some kind of new setting.

Ping tunnel endpoint test fails

Shadow Hawkins on Wednesday, 15 August 2012 19:33:34

So this is a bug in Snow Leopard and/or AICCU? Or still a configuration issue on my machine?

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Wednesday, 15 August 2012 19:53:26

As it happens with normal Ethernet interfaces too, not much AICCU can do about it, thus most very likely something of a bug that started between Snow Leopard and Mountain Lion.

Ping tunnel endpoint test fails

Shadow Hawkins on Friday, 17 August 2012 12:04:05

Should I file a bug report for AICCU, anyway? For OS X? (Good luck :)

Ping tunnel endpoint test fails

Jeroen Massar SixXS Staff

on Friday, 17 August 2012 12:43:59

Should I file a bug report for AICCU, anyway?

It is not a problem in AICCU.

For OS X? (Good luck :)

You can always complain on ipv6-dev@lists.apple.com And file bugs here: bugreporter.apple.com/, I've just filed But before you do that, check that in System Preferences -> Security & Privacy -> Firewall -> Firewall Options you did not enable "Enable stealth mode". Toggling that for me allows one to ping the local interface again. It is a bit strange that they apply this rule also to packets from the local host. And obviously ip6fw is not involved in any of this...

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