SixXS::Sunset 2017-06-06

Ticket ID: SIXXS #889639
Ticket Status: User

PoP: uschi02 - Your.Org, Inc. (Chicago, Illinois)

No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Monday, 29 December 2008 18:00:54
Tag [/code] is not closed
State change: user Locked
[ch] Jeroen Massar SixXS Staff on Monday, 29 December 2008 18:46:46
Message is Locked
The state of this ticket has been changed to user
No IPv6 endpoint ping after tunnel type switch
[ch] Jeroen Massar SixXS Staff on Monday, 29 December 2008 18:49:55
tun2: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet6 fe80::20f:9fff:fed7:939b%tun2 -> prefixlen 64 scopeid 0xe
inet6 fe80::4878:f:bc:2%tun2 -> prefixlen 64 scopeid 0xe
inet6 2001:4978:f:bc::2 -> 2001:4978:f:bc::1 prefixlen 128
Generally, *BSD's state "Opened by PID xxxx", I don't see this here (though maybe NetBSD doesn't do that), is aiccu really using this device? Where is the output of verbose AICCU? Which would also show version numbers and if the IF_HEAD stuff is being correctly used or not (generally AYIYA issues on *nix is caused by that, as the actual packet send out then is incorrect...). You still have 2001:4830:1263:1::/64 on another interface, when you are trying to do ping etc, are you sure that you are using the correct source addresses?
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Monday, 29 December 2008 19:27:14
Tag [/code] is not closed
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Monday, 29 December 2008 21:13:38
Tag [/code] is not closed
No IPv6 endpoint ping after tunnel type switch
[ch] Jeroen Massar SixXS Staff on Monday, 29 December 2008 22:27:05
When no valid AYIYA packets are received on the PoP the PoP also doesn't bring the <tunnel>::1 address up either, as the is no interface to put them on as it is not up then. Next to that, what path are you trying to take there?
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Tuesday, 30 December 2008 02:15:19
Tag [/code] is not closed
No IPv6 endpoint ping after tunnel type switch
[ch] Jeroen Massar SixXS Staff on Monday, 29 December 2008 22:25:12
I don't see HAS_IFHEAD or NEED_IFHEAD in there, as such most very likely you didn't compile it properly. Also, one can set the daemonize false flag, so that everything goes to the console and it doesn't detach; maybe your syslog splits the messages apart as some have different priorities from others. tcpdumping/tsharking the tunnel interface does not help much, as mentioned on the reporting problem checklist, you have to look at the underlying interface (thus eth0 etc); and then still if one sees them there it doesn't mean they actually go outbound as a firewall can block them.
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Tuesday, 30 December 2008 02:11:18
Tag [/code] is not closed
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Tuesday, 30 December 2008 15:43:03
My problem seems similar to this issue. Could it be the same underlying problem? It is the same PoP, and I had changed tunnel type. Thanks.
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Tuesday, 30 December 2008 16:56:04
Here is a full verbose aiccu startup log:
sock_getline() : "200 SixXS TIC Service on noc.sixxs.net ready (http://www.sixxs.net)" sock_printf() : "client TIC/draft-00 AICCU/2007.01.15-console-kame NetBSD/4.0.1_PATCH" sock_getline() : "200 Client Identity accepted" sock_printf() : "get unixtime" sock_getline() : "200 1230652038" sock_printf() : "username GDD1-SIXXS" sock_getline() : "200 Choose your authentication challenge please" sock_printf() : "challenge md5" sock_getline() : "200 *challenge*" sock_printf() : "authenticate md5 *response*" sock_getline() : "200 Succesfully logged in using md5 as GDD1-SIXXS (Gary David Duzan) from 2001:7b8:3:4f:202:b3ff:fe46:bec" sock_printf() : "tunnel show T14292" sock_getline() : "201 Showing tunnel information for T14292" sock_getline() : "TunnelId: T14292" sock_getline() : "Type: ayiya" sock_getline() : "IPv6 Endpoint: 2001:4978:f:bc::2" sock_getline() : "IPv6 POP: 2001:4978:f:bc::1" sock_getline() : "IPv6 PrefixLength: 64" sock_getline() : "Tunnel MTU: 1280" sock_getline() : "Tunnel Name: Wheel Tunnel 2" sock_getline() : "POP Id: uschi02" sock_getline() : "IPv4 Endpoint: ayiya" sock_getline() : "IPv4 POP: 216.14.98.22" sock_getline() : "UserState: enabled" sock_getline() : "AdminState: enabled" sock_getline() : "Password: *password*" sock_getline() : "Heartbeat_Interval: 60" sock_getline() : "202 Done" Succesfully retrieved tunnel information for T14292 sock_printf() : "QUIT Nothing Comes Easy" Tunnel Information for T14292: POP Id : uschi02 IPv6 Local : 2001:4978:f:bc::2/64 IPv6 Remote : 2001:4978:f:bc::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled [tun-start] Trying Configured TUN/TAP interface tun1... [tun-start] Using TUN/TAP interface tun1 [tun-start] Setting TUNSIFMODE for tun1 [tun-start] Setting TUNSIFHEAD for tun1 add net default: gateway 2001:4978:f:bc::1 [AYIYA-start] : Anything in Anything (draft-02) [AYIYA-tun->tundev] : (Socket to TUN) started
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Thursday, 01 January 2009 22:57:08
A newly configured tunnel has the same problem, so I'll be focusing on network issues. Thanks.
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Friday, 02 January 2009 12:38:19
Actually, starting the same tunnel on another system elsewhere on the Internet (Florida) with a working static proto-41 tunnel gives me largely the same result, though with an extra "Host is down" error:
Tunnel Information for T14292: POP Id : uschi02 IPv6 Local : 2001:4978:f:bc::2/64 IPv6 Remote : 2001:4978:f:bc::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled [tun-start] Trying Configured TUN/TAP interface tun1... [tun-start] Using TUN/TAP interface tun1 [tun-start] Setting TUNSIFMODE for tun1 [tun-start] Setting TUNSIFHEAD for tun1 [AYIYA-start] : Anything in Anything (draft-02) [AYIYA-tun->tundev] : (Socket to TUN) started [tun-tundev->tun] Read error on Tun Device: Host is down (64)
It is the same for a newly configured tunnel:
Tunnel Information for T18907: POP Id : uschi02 IPv6 Local : 2001:4978:f:250::2/64 IPv6 Remote : 2001:4978:f:250::1/64 Tunnel Type : ayiya Adminstate : enabled Userstate : enabled [tun-start] Trying Configured TUN/TAP interface tun1... [tun-start] Using TUN/TAP interface tun1 [tun-start] Setting TUNSIFMODE for tun1 [tun-start] Setting TUNSIFHEAD for tun1 [AYIYA-start] : Anything in Anything (draft-02) [AYIYA-tun->tundev] : (Socket to TUN) started [tun-tundev->tun] Read error on Tun Device: Host is down (64)
I also did some basic testing of port 5072 UDP connectivity from my original FIOS site to my Florida site, and it seemed to be getting through:
########################################################################### brain { ~ } % python2.4 Python 2.4.5 (#1, Aug 8 2008, 18:17:25) [GCC 4.1.3 20080202 prerelease (NetBSD nb1 20080202)] on netbsd4 Type "help", "copyright", "credits" or "license" for more information.
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.sendto("bar", ("66.251.193.82", 5072))
3
s.sendto("bar", ("66.251.193.82", 5072)); s.recvfrom(1024)
3 ("echo: 'bar'", ('66.251.193.82', 5072))
s.sendto("bar", ("66.251.193.82", 5072)); s.recvfrom(1024)
3 ("echo: 'bar'", ('66.251.193.82', 5072))
s.sendto("barnone", ("66.251.193.82", 5072)); s.recvfrom(1024)
7 ("echo: 'barnone'", ('66.251.193.82', 5072))
########################################################################### xen1 { ~ } % python2.4 Python 2.4.5 (#1, Aug 10 2008, 09:35:26) [GCC 4.1.3 20070620 prerelease (NetBSD nb1 20070620)] on netbsd4 Type "help", "copyright", "credits" or "license" for more information.
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.bind(("0.0.0.0", 5072))
while True:
... data, addr = s.recvfrom(1024) ... print "received %r from %r" % (data,addr) ... s.sendto("echo: %r" % (data,), addr) ... received 'bar' from ('96.227.94.168', 57538) 11 received 'bar' from ('96.227.94.168', 50253) 11 received 'barnone' from ('96.227.94.168', 50253) 15 ###########################################################################
This is looking more like a general problem with dynamic tunnel setup on the uschi02 PoP. This issue may be related.
No IPv6 endpoint ping after tunnel type switch
[us] Shadow Hawkins on Saturday, 03 January 2009 02:01:31
For whatever reason both the original and the new tunnel are working fine now. I didn't do anything from my end, so it must have been the PoP or something in the network. Regardless of cause, the ticket can be considered resolved. Thanks.

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

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