SixXS::Sunset 2017-06-06

Unable to ping IPv6 PoP
[gb] Shadow Hawkins on Friday, 19 September 2014 18:16:58
I'm stumped, any clues? I'm unable to ping the PoP IPv6 2a01:348:6:7a1::1, everything appears to be as suggested in the IPv6 page from the FreeBSD handbook and the excellent https://www.sixxs.net/faq/ Although there is a firewall FreeBSD's IPFW it is open for ipv6 Broadband is PlusNet in the UK with Netgear DG834Gv5 and all traffic forwarded to the FreeBSD 10 box. Tunnel Information for T154777 The configuration for this tunnel looks like: Tunnel Name My First Tunnel PoP Name gblon02 PoP Location London, United Kingdom (Great Britain) United Kingdom (Great Britain) PoP IPv4 77.75.104.126 TIC Server tic.sixxs.net (default in AICCU) Your Location London, United Kingdom (Great Britain) United Kingdom (Great Britain) Your IPv4 Static, currently 80.229.143.200 IPv6 Prefix 2a01:348:6:7a1::1/64 PoP IPv6 2a01:348:6:7a1::1 Your IPv6 2a01:348:6:7a1::2 Created 2014-09-18 17:31:02 UTC Last Alive never Last Dead 2014-09-18 17:31:02 UTC Uptime 0 days (based on latency check) Config State Enabled PoP Status Live Tunnel Status on the PoP schnittke# ping6 -v -c 3 -i 5 2a01:348:6:7a1::1 PING6(56=40+8+8 bytes) 2a01:348:6:7a1::2 --> 2a01:348:6:7a1::1 --- 2a01:348:6:7a1::1 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss The frustrating thing is that I can see the three requests going out (seq 0-2) and there is plenty coming in! # tcpdump -i gif0 tcpdump: WARNING: gif0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 18:35:39.187409 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16 18:35:44.186961 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:35:44.187943 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1, length 16 18:35:45.187058 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:35:46.187009 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:35:49.187978 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 2, length 16 18:35:54.187988 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:35:54.578897 IP6 gw-1954.lon-02.gb.sixxs.net > cl-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1220, length 988 18:35:54.578950 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo reply, seq 1220, length 988 18:35:55.187955 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:35:56.187980 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:36:54.585330 IP6 gw-1954.lon-02.gb.sixxs.net > cl-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1221, length 988 18:36:54.585433 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo reply, seq 1221, length 988 18:36:59.584972 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:37:00.584996 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:37:01.585017 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:37:54.591670 IP6 gw-1954.lon-02.gb.sixxs.net > cl-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 1222, length 988 18:37:54.591743 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo reply, seq 1222, length 988 18:37:59.590967 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:38:00.590967 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:38:01.590965 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:38:09.044086 IP6 cl-1954.lon-02.gb.sixxs.net.ntp > www.nierle.com.ntp: NTPv4, Client, length 48 18:38:14.043995 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:38:15.043945 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 18:38:16.044005 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24 # ifconfig em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC> ether 00:c0:9f:3b:95:17 inet 192.168.202.5 netmask 0xffffff00 broadcast 192.168.202.255 inet6 fe80::2c0:9fff:fe3b:9517%em0 prefixlen 64 scopeid 0x1 inet 192.168.202.4 netmask 0xffffffff broadcast 192.168.202.4 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (100baseTX <full-duplex>) status: active xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=82009<RXCSUM,VLAN_MTU,WOL_MAGIC,LINKSTATE> ether 00:50:da:43:84:ed inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255 inet6 fe80::250:daff:fe43:84ed%xl0 prefixlen 64 scopeid 0x2 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (100baseTX <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> gif0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> metric 0 mtu 1280 tunnel inet 192.168.0.2 --> 77.75.104.126 inet6 2a01:348:6:7a1::2 prefixlen 64 inet6 fe80::2c0:9fff:fe3b:9517%gif0 prefixlen 64 scopeid 0x4 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> # route -v get -inet6 2a01:348:6:7a1::1 RTA_DST: inet6 2a01:348:6:7a1::1; RTA_IFP: link ; RTM_GET: Report Metrics: len 176, pid: 0, seq 1, errno 0, flags:<UP,GATEWAY,HOST,STATIC> locks: inits: sockaddrs: <DST,IFP> gw-1954.lon-02.gb.sixxs.net link#0 route to: gw-1954.lon-02.gb.sixxs.net destination: 2a01:348:6:7a1:: mask: ffff:ffff:ffff:ffff:: fib: 0 interface: gif0 flags: <UP,DONE> recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1280 1 0 locks: inits: sockaddrs: <DST,GATEWAY,NETMASK,IFP,IFA,BRD> 2a01:348:6:7a1:: link#4 ffff:ffff:ffff:ffff:: gif0 cl-1954.lon-02.gb.sixxs.net default # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.0.1 UGS 0 106146 xl0 127.0.0.1 link#3 UH 0 19756 lo0 192.168.0.0/24 link#2 U 0 6478 xl0 192.168.0.2 link#2 UHS 0 0 lo0 192.168.202.0/24 link#1 U 0 48014 em0 192.168.202.4 link#1 UHS 0 0 lo0 => 192.168.202.4/32 link#1 U 0 0 em0 192.168.202.5 link#1 UHS 0 53676 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2a01:348:6:7a1::1 UGS gif0 ::1 link#3 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2a01:348:6:7a1::/64 link#4 U gif0 2a01:348:6:7a1::2 link#4 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#1 U em0 fe80::2c0:9fff:fe3b:9517%em0 link#1 UHS lo0 fe80::%xl0/64 link#2 U xl0 fe80::250:daff:fe43:84ed%xl0 link#2 UHS lo0 fe80::%lo0/64 link#3 U lo0 fe80::1%lo0 link#3 UHS lo0 fe80::%gif0/64 link#4 U gif0 fe80::2c0:9fff:fe3b:9517%gif0 link#4 UHS lo0 ff01::%em0/32 fe80::2c0:9fff:fe3b:9517%em0 U em0 ff01::%xl0/32 fe80::250:daff:fe43:84ed%xl0 U xl0 ff01::%lo0/32 ::1 U lo0 ff01::%gif0/32 2a01:348:6:7a1::2 U gif0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::2c0:9fff:fe3b:9517%em0 U em0 ff02::%xl0/32 fe80::250:daff:fe43:84ed%xl0 U xl0 ff02::%lo0/32 ::1 U lo0 ff02::%gif0/32 2a01:348:6:7a1::2 U gif0 net.inet6.ip6.forwarding: 1 net.inet6.ip6.accept_rtadv: 0 The only error appears to be rtadvd[1367]: non-zero lifetime RA on RA receiving interface gif0. Ignored. Any help appreciated, Thanks, Alan
Unable to ping IPv6 PoP
[ch] Jeroen Massar SixXS Staff on Friday, 19 September 2014 21:21:26
Broadband is PlusNet in the UK with Netgear DG834Gv5 and all traffic forwarded to the FreeBSD 10 box.
How is "all forwarded"?
18:35:39.187409 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16
18:35:44.186961 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24
Why is your host doing neighbor solicitations on a point-to-point tunnel? Also, why is it doing that after just sending a packet to that host? (PS: the '-n' option of tcpdump is very useful, hostnames are not always useful in debugging)
tcpdump: WARNING: gif0: no IPv4 address assigned
You are looking at the IPv6 interface; why not at the tunnel interface, are the tunneled packets going anywhere at all?
tunnel inet 192.168.0.2 --> 77.75.104.126
Does your NAT box understand + support protocol 41?
The only error appears to be rtadvd[1367]: non-zero lifetime RA on RA receiving interface gif0. Ignored.
Why do you have rtadvd enabled on a tunnel interface with static IP addresses?
Unable to ping IPv6 PoP
[gb] Shadow Hawkins on Friday, 19 September 2014 23:40:49
Jeroen Massar wrote:
>> Broadband is PlusNet in the UK with Netgear DG834Gv5 and all traffic forwarded to the FreeBSD 10 box.
How is "all forwarded"?
The Netgear router has something they call Default DMZ Server which forwards all undefined services to a specified ip address, in this case 192.168.0.2
18:35:39.187409 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, echo request, seq 0, length 16
18:35:44.186961 IP6 cl-1954.lon-02.gb.sixxs.net > gw-1954.lon-02.gb.sixxs.net: ICMP6, neighbor solicitation, who has gw-1954.lon-02.gb.sixxs.net, length 24
Why is your host doing neighbor solicitations on a point-to-point tunnel? Also, why is it doing that after just sending a packet to that host? (PS: the '-n' option of tcpdump is very useful, hostnames are not always useful in debugging)
Unable to track down cause of neighbor solicitation, will try to investigate further. Thanks for the '-n' option, gives more transparent output. Shows that gif0 (2a01:348:6:7a1::2) is sending request but not receiving a reply. Assume echo request at 23:46:56.988723 is instigated by PoPv6 ping followed by reply. Unsure what might be causing this box (gif0) to send but not receive reply when the PoP is able to send and receive a reply. Perhaps as you say it's something to do with nat in the Netgear ADSL2+ router though not sure how to check. # tcpdump -n -i gif0 tcpdump: WARNING: gif0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on gif0, link-type NULL (BSD loopback), capture size 65535 bytes capability mode sandbox enabled 23:46:29.831350 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 0, length 16 23:46:30.831667 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 1, length 16 23:46:31.831651 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 2, length 16 23:46:34.831830 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 23:46:35.831585 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 23:46:36.831595 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 23:46:56.988723 IP6 2a01:348:6:7a1::1 > 2a01:348:6:7a1::2: ICMP6, echo request, seq 1531, length 988 23:46:56.988783 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo reply, seq 1531, length 988 23:47:01.988547 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 23:47:02.988637 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 23:47:03.988576 IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24
tcpdump: WARNING: gif0: no IPv4 address assigned
You are looking at the IPv6 interface; why not at the tunnel interface, are the tunneled packets going anywhere at all?
Think it's saying no IPv4 address assigned because the gif interface uses the tunnel rather than has the ip4 addresses direct. gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 192.168.0.2 --> 77.75.104.126 inet6 2a01:348:6:7a1::2 --> 2a01:348:6:7a1::1 prefixlen 128 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> # ping -c 2 77.75.104.126 PING 77.75.104.126 (77.75.104.126): 56 data bytes 64 bytes from 77.75.104.126: icmp_seq=0 ttl=52 time=30.085 ms 64 bytes from 77.75.104.126: icmp_seq=1 ttl=52 time=29.157 ms --- 77.75.104.126 ping statistics --- 2 packets transmitted, 2 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 29.157/29.621/30.085/0.464 ms # ping6 -v -c 3 2a01:348:6:7a1::1 PING6(56=40+8+8 bytes) 2a01:348:6:7a1::2 --> 2a01:348:6:7a1::1 --- 2a01:348:6:7a1::1 ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -n -i xl0 host 77.75.104.126 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 00:36:24.380403 IP 192.168.0.2 > 77.75.104.126: ICMP echo request, id 53812, seq 0, length 64 00:36:24.408868 IP 77.75.104.126 > 192.168.0.2: ICMP echo reply, id 53812, seq 0, length 64 00:36:25.382475 IP 192.168.0.2 > 77.75.104.126: ICMP echo request, id 53812, seq 1, length 64 00:36:25.411312 IP 77.75.104.126 > 192.168.0.2: ICMP echo reply, id 53812, seq 1, length 64 00:36:33.574703 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 0, length 16 00:36:34.575531 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 1, length 16 00:36:35.580653 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 2, length 16 00:36:38.574569 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 00:36:39.574501 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 00:36:40.574570 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 00:36:57.360326 IP 77.75.104.126 > 192.168.0.2: IP6 2a01:348:6:7a1::1 > 2a01:348:6:7a1::2: ICMP6, echo request, seq 1581, length 988 00:36:57.361225 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo reply, seq 1581, length 988 00:37:02.360570 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 00:37:03.360583 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 00:37:04.360592 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24
tunnel inet 192.168.0.2 --> 77.75.104.126
Does your NAT box understand + support protocol 41?
Doubt it, not sure how to check, though as traffic was getting though my assumption was that it doesn't understand and just sends it through to the FreeBSD box.
The only error appears to be rtadvd[1367]: non-zero lifetime RA on RA receiving interface gif0. Ignored.
Why do you have rtadvd enabled on a tunnel interface with static IP addresses?
Error on my part, now disabled.
Unable to ping IPv6 PoP
[ch] Jeroen Massar SixXS Staff on Saturday, 20 September 2014 00:45:44
The Netgear router has something they call Default DMZ Server which forwards all undefined services to a specified ip address, in this case 192.168.0.2
Maybe not _all_ packets... Note that the PoP does not see incoming proto-41 packets either, at least no valid ones relating to your tunnel.
Doubt it, not sure how to check, though as traffic was getting though my assumption was that it doesn't understand and just sends it through to the FreeBSD box.
You might want to consider using AYIYA, as it is made for crossing NATs...
Unable to ping IPv6 PoP
[gb] Shadow Hawkins on Saturday, 20 September 2014 06:04:54
Jeroen Massar wrote:
> The Netgear router has something they call Default DMZ Server which forwards all undefined services to a specified ip address, in this case 192.168.0.2 Maybe not _all_ packets... Note that the PoP does not see incoming proto-41 packets either, at least no valid ones relating to your tunnel.
Doubt it, not sure how to check, though as traffic was getting though my assumption was that it doesn't understand and just sends it through to the FreeBSD box.
You might want to consider using AYIYA, as it is made for crossing NATs...
Have just changed the tunnel type, so hopefully will fair better with AYIYA. Should have planned better, sorry. Also thanks for the insights into tcpdump, a great tool that I will be using more of.
Unable to ping IPv6 PoP
[gb] Shadow Hawkins on Saturday, 20 September 2014 08:19:51
Alan Hicks wrote:
Jeroen Massar wrote:
> The Netgear router has something they call Default DMZ Server which forwards all undefined services to a specified ip address, in this case 192.168.0.2 Maybe not _all_ packets... Note that the PoP does not see incoming proto-41 packets either, at least no valid ones relating to your tunnel.
Doubt it, not sure how to check, though as traffic was getting though my assumption was that it doesn't understand and just sends it through to the FreeBSD box.
You might want to consider using AYIYA, as it is made for crossing NATs...
Have just changed the tunnel type, so hopefully will fair better with AYIYA. Should have planned better, sorry. Also thanks for the insights into tcpdump, a great tool that I will be using more of.
Alas still unable to ping. The error I'm getting is sixxs-aiccu: [tun-tun->tundev] Error while writing to TUN: 0 != 1032 # sixxs-aiccu test /usr/local/etc/aiccu.conf Tunnel Information for T154777: POP Id : gblon02 IPv6 Local : 2a01:348:6:7a1::2/64 IPv6 Remote : 2a01:348:6:7a1::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled # ifconfig tun0 tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280 tunnel inet 192.168.202.5 --> 77.75.104.126 inet6 2a01:348:6:7a1::2 prefixlen 64 inet6 fe80::2c0:9fff:fe3b:9517%tun0 prefixlen 64 scopeid 0x4 inet6 fe80::48:6:7a1:2%tun0 prefixlen 64 scopeid 0x4 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> % ping6 -v -c 2 2a01:348:6:7a1::1 PING6(56=40+8+8 bytes) 2a01:348:6:7a1::2 --> 2a01:348:6:7a1::1 --- 2a01:348:6:7a1::1 ping6 statistics --- 2 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -i xl0 -n host 77.75.104.126 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 08:15:40.822356 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 0, length 16 08:15:41.822795 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 1, length 16 08:15:45.811832 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2.123 > 2a00:1ed0:1::74.123: NTPv4, Client, length 48 08:15:45.821615 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 08:15:46.821724 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 08:15:47.821769 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, neighbor solicitation, who has 2a01:348:6:7a1::1, length 24 08:16:00.688730 IP 77.75.104.126.5072 > 192.168.0.2.4160: UDP, length 1072
Unable to ping IPv6 PoP
[ch] Jeroen Massar SixXS Staff on Saturday, 20 September 2014 10:11:16
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
tunnel inet 192.168.202.5 --> 77.75.104.126
You might want to destroy that interface as that is a protocol 41 interface. AICCU does not overrule configuration that is already in place, as they might have been made on purpose and with a reason.
08:15:40.822356 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 0, length 16
Those are proto-41 packets, not AYIYA.
Unable to ping IPv6 PoP
[gb] Shadow Hawkins on Saturday, 20 September 2014 12:55:23
Jeroen Massar wrote:
> tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
tunnel inet 192.168.202.5 --> 77.75.104.126
You might want to destroy that interface as that is a protocol 41 interface. AICCU does not overrule configuration that is already in place, as they might have been made on purpose and with a reason.
08:15:40.822356 IP 192.168.0.2 > 77.75.104.126: IP6 2a01:348:6:7a1::2 > 2a01:348:6:7a1::1: ICMP6, echo request, seq 0, length 16
Those are proto-41 packets, not AYIYA.
All working. Thank you for your enlightenment I still have lots to learn about networking, and also for your endless patience for which I am truly appreciative. Alan

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

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker