|
Ticket ID: SIXXS #5129209 Ticket Status: Resolved PoP: decgn01 - NetCologne Gesellschaft fur Telekommunikation mbH (Cologne)
Tunnel does not work more
![[de]](/s/countries/de.gif) Shadow Hawkins on Tuesday, 05 July 2011 11:34:38
The tunnel is not working more. Ping to ipv6 hosts is not possible. local ipv6 does work.the remote end of the tunnel is not pingable.
Tunnel broken, endpoint not pingable
Shadow Hawkins on Sunday, 03 July 2011 03:04:13
Setup worked ~2weeks fine, this evening it breaks and i dont know why, i cannot ping the ipv6 endpoint (or something else...).
Im using aiccu on gentoo, heres my config...
ifconfig
sixxs Protokoll:UNSPEC Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 Adresse: fe80::4cd0:ff00:922:2/64 Gltigkeitsbereich:Verbindung
inet6 Adresse: 2001:4dd0:ff00:922::2/64 Gltigkeitsbereich:Global
UP PUNKTZUPUNKT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:100 errors:0 dropped:0 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlnge:500
RX bytes:0 (0.0 B) TX bytes:8500 (8.3 KiB)
ip -6 route show
2001:4dd0:ff00:922::/64 dev sixxs proto kernel metric 256
fe80::/64 dev eth0 proto kernel metric 256
fe80::/64 dev sixxs proto kernel metric 256
ff00::/8 dev eth0 metric 256
ff00::/8 dev sixxs metric 256
default via 2001:4dd0:ff00:922::1 dev sixxs metric 1024
no active firewall...
where should i search the problem!? it worked, but without changing any tunnel-related configuration on the server it stops working :/
Which info should i provide additionaly?
State change: confirmed
The state of this ticket has been changed to confirmed
State change: resolved
The state of this ticket has been changed to resolved
Tunnel broken, endpoint not pingable
I can't ping your endpoint, but I can see packets going in and out, thus it is now resolved.
Tunnel broken, endpoint not pingable
Shadow Hawkins on Monday, 04 July 2011 15:24:26
My AYIYA tunnels also don't work anymore while my heartbeat tunnel still does.
There were neither reconfigurations nor reboots nor anything.
The tunnel endpoints which don't work anymore are
* 2001:4dd0:ff00:8fd::2
* 2001:4dd0:ff00:9a1::2
They are pingable from outside normally, so when they are not, there must be still an error.
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (10.0.1.14)
### 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
...
######
Did this work? [Y/n] y
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (78.35.24.124)
### 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 78.35.24.124 (78.35.24.124) 56(84) bytes of data.
64 bytes from 78.35.24.124: icmp_req=1 ttl=55 time=10.7 ms
64 bytes from 78.35.24.124: icmp_req=2 ttl=55 time=11.1 ms
64 bytes from 78.35.24.124: icmp_req=3 ttl=55 time=10.5 ms
--- 78.35.24.124 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 10.582/10.823/11.182/0.258 ms
######
Did this work? [Y/n] y
####### [3/8] Traceroute to the PoP (78.35.24.124) 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 78.35.24.124 (78.35.24.124), 30 hops max, 60 byte packets
[DELETED]
6 rtdecix2-g00.netcologne.de (80.81.193.212) 51.747 ms 49.845 ms 49.931 ms
7 core-pg2-t93.netcologne.de (89.1.16.13) 10.769 ms 10.653 ms 10.889 ms
8 core-eup2-t42.netcologne.de (87.79.16.213) 12.161 ms 11.858 ms 12.262 ms
9 sixxs-pop1.netcologne.net (78.35.24.124) 10.953 ms 10.795 ms 10.884 ms
######
Did this work? [Y/n] y
###### [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
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.072 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.063 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.052/0.062/0.072/0.010 ms
######
Did this work? [Y/n]
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4dd0:ff00:9a1::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:4dd0:ff00:9a1::2(2001:4dd0:ff00:9a1::2) 56 data bytes
64 bytes from 2001:4dd0:ff00:9a1::2: icmp_seq=1 ttl=64 time=0.062 ms
64 bytes from 2001:4dd0:ff00:9a1::2: icmp_seq=2 ttl=64 time=0.067 ms
64 bytes from 2001:4dd0:ff00:9a1::2: icmp_seq=3 ttl=64 time=0.074 ms
--- 2001:4dd0:ff00:9a1::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.062/0.067/0.074/0.010 ms
######
Did this work? [Y/n]
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4dd0:ff00:9a1::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 successful then this could be both
### a firewalling and a routing/interface problem
PING 2001:4dd0:ff00:9a1::1(2001:4dd0:ff00:9a1::1) 56 data bytes
--- 2001:4dd0:ff00:9a1::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
######
Did this work? [Y/n] n
Tunnel broken, endpoint not pingable
2001:4dd0:ff00:8fd::2 which is currently located at 84.23.75.23 is returning me port unreachables for the source port 52629 that it is sending proper AYIYA packets from, thus indeed it will not work.
2001:4dd0:ff00:9a1::2 does not respond at all.
Instead of solely showing the output of AICCU test, which I do hope you are not running at the same time that another AICCU instance is running, please provide the details requested in that big yellow/orange box.
Tunnel broken, endpoint not pingable, PoP sends its UDP answers to the wrong port
Shadow Hawkins on Monday, 04 July 2011 17:01:59
Actually at the time of testing all other AICCU instances were killed and were started afterwards again to make sure you could test the connection.
In order to suffice with the ticket requirements I'll give the required information here:
2001:4dd0:ff00:8fd::2 (tunnel id T72713) is permanentely located at 84.23.75.23 which is a virtual machine at an ISP. Since I don't have control over the host machine I have to use AYIYA tunnels which worked until more or less 14:00 CEST.
There is no packet filtering as only services are running which are to be offered to the public:
84-23-75-23:~# iptables -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
AICCU verbose start
84-23-75-23:~# invoke-rc.d aiccu start
Tunnel Information for T71173:
POP Id : decgn01
IPv6 Local : 2001:4dd0:ff00:8fd::2/64
IPv6 Remote : 2001:4dd0:ff00:8fd::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
OS and AICCU versions
AICCU is 20070115
84-23-75-23:~# lsb_release -a
No LSB modules are available.
Distributor ID:Debian
Description:Debian GNU/Linux 6.0.2 (squeeze)
Release:6.0.2
Codename:squeeze
Interface list
84-23-75-23:~# ip ad li
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/void
inet 84.23.75.23/32 scope global venet0:0
11: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN qlen 500
link/none
inet6 2001:4dd0:ff00:8fd::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::4cd0:ff00:8fd:2/64 scope link
valid_lft forever preferred_lft forever
IPv4 Routing
84-23-75-23:~# ip ro li
default dev venet0 scope link
IPv6 Routing
84-23-75-23:~# ip -6 ro li
2001:4dd0:ff00:8fd::/64 dev sixxs metric 256 expires 21333777sec mtu 1280 advmss 1220 hoplimit 4294967295
fe80::/64 dev sixxs metric 256 expires 21333777sec mtu 1280 advmss 1220 hoplimit 4294967295
default via 2001:4dd0:ff00:8fd::1 dev sixxs metric 1024 expires 21333777sec mtu 1280 advmss 1220 hoplimit 4294967295
Personal observations / TCPDUMP
When pinging the IPv6 tunnel at the POP, I see the traffic returning on port 52629 as you wrote. The problem is, that AICCU is listening at another port:
84-23-75-23:~# netstat -nua
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
udp 0 0 84.23.75.23:49216 78.35.24.124:5072 ESTABLISHED
A tcpdump at the same time shows that the PoP is sending replies to a completely different port, e.g. when I do
84-23-75-23:~# ping6 -c 3 2001:4dd0:ff00:8fd::1
PING 2001:4dd0:ff00:8fd::1(2001:4dd0:ff00:8fd::1) 56 data bytes
--- 2001:4dd0:ff00:8fd::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms
the tcpdump says this:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
16:39:46.221095 IP 78.35.24.124.5072 > 84.23.75.23.16576: UDP, length 148
16:39:46.221130 IP 84.23.75.23 > 78.35.24.124: ICMP 84.23.75.23 udp port 16576 unreachable, length 184
16:39:47.196701 IP 84.23.75.23.49216 > 78.35.24.124.5072: UDP, length 148
16:39:47.221132 IP 78.35.24.124.5072 > 84.23.75.23.16576: UDP, length 148
16:39:47.221170 IP 84.23.75.23 > 78.35.24.124: ICMP 84.23.75.23 udp port 16576 unreachable, length 184
16:39:47.223648 IP 84.23.75.23.49216 > 78.35.24.124.5072: UDP, length 44
16:39:48.196641 IP 84.23.75.23.49216 > 78.35.24.124.5072: UDP, length 148
16:39:48.221070 IP 78.35.24.124.5072 > 84.23.75.23.16576: UDP, length 148
16:39:48.221124 IP 84.23.75.23 > 78.35.24.124: ICMP 84.23.75.23 udp port 16576 unreachable, length 184
16:39:55.870549 IP 78.35.24.124.5072 > 84.23.75.23.16576: UDP, length 148
16:39:55.870593 IP 84.23.75.23 > 78.35.24.124: ICMP 84.23.75.23 udp port 16576 unreachable, length 184
(As of writing this report, the port the PoP is sending its answers to, obviously has changed, nonetheless it's the wrong port.)
I hope right now I didn't forget to write relevant information again. In my previous post I actually did most of the steps.
2001:4dd0:ff00:9a1::2 is behind a NAT and I don't have access to the router/firewall, so forget about that at the moment. The only thing I can say is that UDPv4 packets are leaving the workstation towards the PoP (checked by tcpdump) but I don't receive any answer. I guess the problem is similar to the one above. If the NAT gateway receives UDP packets on the wrong port it will drop them obviously.
Same problem ...
Shadow Hawkins on Monday, 04 July 2011 16:34:10
Hello,
on my tunnel T72377 I have exaclty the same symptoms with AICCU Quick Connectivity Test as Jens Reinsberger.
I get no error-messages from aiccu even with "verbose true".
I can send packets trough tunnel but i got no packet back.
My tunnel is:
2001:4dd0:ff00:983::2/64
Thank you.
Same problem ...
Please read that big yellow/orange box which is there for a reason, and provide the requested details.
Tunnel broken, endpoint not pingable
Shadow Hawkins on Monday, 04 July 2011 15:28:36
I got a similar problem at 14:00h +2 today. The inner tunnel endpoint is not pingable anymore.
It's seems to me that AYIAY is broken on that POP
local end 2001:4dd0:ff00:5::2/64
Tunnel broken, endpoint not pingable
I see packets flowing over your tunnel. For the rest, please provide all details requested by that big yellow/orange box.
Tunnel broken, endpoint not pingable
Shadow Hawkins on Monday, 04 July 2011 17:02:58
SHE3-SIXXS/T24759
Inner tunnel Endpoint does not answer pings.
Debian
Linux phoebe 2.6.32-5-kirkwood #1 Wed Jan 12 15:27:07 UTC 2011 armv5tel GNU/Linux
aiccu 20070115-14
My machine is behind a nating CPE owned by netcolonge.
# ip -6 addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:4dd0:ff02::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::x:xxff:fex:x/64 scope link
valid_lft forever preferred_lft forever
30: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qlen 500
inet6 2001:4dd0:ff00:5::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::4cd0:ff00:5:2/64 scope link
valid_lft forever preferred_lft forever
# ip -6 route
2001:4dd0:ff00:5::/64 dev sixxs proto kernel metric 256 mtu 1400 advmss 1340 hoplimit 0
2001:4dd0:ff02::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 0
fe80::/64 dev sixxs proto kernel metric 256 mtu 1400 advmss 1340 hoplimit 0
default via 2001:4dd0:ff00:5::1 dev sixxs metric 1024 mtu 1400 advmss 1340 hoplimit 0
there is no firewall and no anit-virus softwareinstalled on this machine.
#######
####### AICCU Quick Connectivity Test
#######
####### [1/8] Ping the IPv4 Local/Your Outer Endpoint (192.168.172.2)
### 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.172.2 (192.168.172.2) 56(84) bytes of data.
64 bytes from 192.168.172.2: icmp_req=1 ttl=64 time=0.071 ms
64 bytes from 192.168.172.2: icmp_req=2 ttl=64 time=0.055 ms
64 bytes from 192.168.172.2: icmp_req=3 ttl=64 time=0.062 ms
--- 192.168.172.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.055/0.062/0.071/0.011 ms
######
####### [2/8] Ping the IPv4 Remote/PoP Outer Endpoint (78.35.24.124)
### 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 78.35.24.124 (78.35.24.124) 56(84) bytes of data.
64 bytes from 78.35.24.124: icmp_req=1 ttl=59 time=49.4 ms
64 bytes from 78.35.24.124: icmp_req=2 ttl=59 time=7.44 ms
64 bytes from 78.35.24.124: icmp_req=3 ttl=59 time=7.35 ms
--- 78.35.24.124 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2005ms
rtt min/avg/max/mdev = 7.354/21.400/49.405/19.802 ms
######
####### [3/8] Traceroute to the PoP (78.35.24.124) 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 78.35.24.124 (78.35.24.124), 30 hops max, 60 byte packets
1 router.pn-aachen.sebastianhoogen.de (192.168.172.1) 0.391 ms 0.637 ms 0.832 ms
2 e320-zva1.netcologne.de (195.14.226.50) 8.393 ms 9.542 ms 10.608 ms
3 TBA1.netcologne.de (78.35.33.237) 11.963 ms 13.552 ms 14.692 ms
4 core-sto1-vl426.netcologne.de (78.35.33.217) 16.194 ms 17.333 ms 18.740 ms
5 core-eup2-t31.netcologne.de (87.79.17.25) 20.229 ms 21.870 ms *
6 sixxs-pop1.netcologne.net (78.35.24.124) 19.263 ms 15.108 ms 16.668 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
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.081 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.106 ms
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2727ms
rtt min/avg/max/mdev = 0.076/0.087/0.106/0.017 ms
######
###### [5/8] Ping the IPv6 Local/Your Inner Tunnel Endpoint (2001:4dd0:ff00:5::2)
### This confirms that your tunnel is configured
### If it doesn't reply then check your interface and routing tables
PING 2001:4dd0:ff00:5::2(2001:4dd0:ff00:5::2) 56 data bytes
64 bytes from 2001:4dd0:ff00:5::2: icmp_seq=1 ttl=64 time=0.083 ms
64 bytes from 2001:4dd0:ff00:5::2: icmp_seq=2 ttl=64 time=0.088 ms
64 bytes from 2001:4dd0:ff00:5::2: icmp_seq=3 ttl=64 time=0.085 ms
--- 2001:4dd0:ff00:5::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.083/0.085/0.088/0.007 ms
######
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4dd0:ff00:5::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 successful then this could be both
### a firewalling and a routing/interface problem
PING 2001:4dd0:ff00:5::1(2001:4dd0:ff00:5::1) 56 data bytes
--- 2001:4dd0:ff00:5::1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2003ms
######
###### [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.
traceroute to noc.sixxs.net (2001:838:1:1:210:dcff:fe20:7c7c), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### [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
traceroute to www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
######
###### ACCU Quick Connectivity Test (done)
### Either the above all works and gives no problems
### or it shows you where what goes wrong
### Check the SixXS FAQ (http://www.sixxs.net/faq/
### for more information and possible solutions or hints
### Don't forget to check the Forums (http://www.sixxs.net/forum/)
### for a helping hand.
### Passing the output of 'aiccu autotest >aiccu.log' is a good idea.
State change: user
The state of this ticket has been changed to user
Tunbel does not work more
I would say, with the amount of information you are providing, that it is broken.
Please read that big yellow/orange box which is there for a reason, and provide the requested details.
Tunnel brocken
Shadow Hawkins on Monday, 04 July 2011 16:32:33
Hello,
my IPv6 tunnel is broken since 2011-07-04 14:19:16 CEST.
A ping6 to my PoP failes with lost packages:
$ ping6 2001:4dd0:ff00:59b::1
PING 2001:4dd0:ff00:59b::1(2001:4dd0:ff00:59b::1) 56 data bytes
^C
--- 2001:4dd0:ff00:59b::1 ping statistics ---
362 packets transmitted, 0 received, 100% packet loss, time 361112ms
Aiccu is running and I also tried to restart the daemon with no success. The IPv4 address of my PoP is reachable:
$ ping 78.35.24.124
PING 78.35.24.124 (78.35.24.124) 56(84) bytes of data.
64 bytes from 78.35.24.124: icmp_seq=1 ttl=50 time=14.0 ms
64 bytes from 78.35.24.124: icmp_seq=2 ttl=50 time=14.1 ms
^C
--- 78.35.24.124 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 14.037/14.078/14.119/0.041 ms
Tunnel information:
Tunnel Nametunnel0
PoP Namedecgn01
PoP LocationCologne, Germany
PoP IPv478.35.24.124
TIC Servertic.sixxs.net (default in AICCU)
Your LocationMunich, Germany
Your IPv4AYIYA
IPv6 Prefix2001:4dd0:ff00:59b::1/64
PoP IPv62001:4dd0:ff00:59b::1
Your IPv62001:4dd0:ff00:59b::2
Created2011-02-12 10:48:13 CEST
Last Alive2011-07-04 14:19:16 CEST
StateAYIYA (automatically enabled on the fly)
The graphs on my tunnel info page also shown empty bars since then.
Yours sincerly,
Alexander Thomas
State change: user
The state of this ticket has been changed to user
Tunnel brocken
Please actually provide the details as requested in that big yellow/orange box, it is there for a reason.
Tunnel brocken
Shadow Hawkins on Monday, 04 July 2011 16:51:59
I have read and followed the "Reporting Problems" section on the Contact page.
I am removing these five pre-filled lines to demonstrate that I really read it.
I am providing the full details as requested on the mentioned Contact page.
If I do not remove this, then please ignore this message as I didn't read it anyway.
------------------------------------------------------------------------------>8
same issues here:
i restarted aiccu
Jul 4 16:43:54 post aiccu: Succesfully retrieved tunnel information for T56793
Jul 4 16:43:54 post kernel: [2672967.546061] sixxs: Disabled Privacy Extensions
Jul 4 16:43:54 post aiccu: AICCU running as PID 25029
Jul 4 16:43:54 post aiccu: [AYIYA-start] : Anything in Anything (draft-02)
Jul 4 16:43:54 post aiccu: [AYIYA-tun->tundev] : (Socket to TUN) started
[...]
post:~# ping6 ipv6.google.com
PING ipv6.google.com(fx-in-x68.1e100.net) 56 data bytes
--- ipv6.google.com ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 5999ms
post:~# ping 78.35.24.124
PING 78.35.24.124 (78.35.24.124) 56(84) bytes of data.
64 bytes from 78.35.24.124: icmp_seq=1 ttl=60 time=0.673 ms
[...]
Tunnel brocken
Please actually provide the details as requested in that big yellow/orange box, it is there for a reason.
Tunbel does not work more
Shadow Hawkins on Monday, 04 July 2011 16:43:09
I can second the issue. Running AICCU. Login works perfectly.
I can reach the tunnel endpoint as well:
2 87.186.224.178 (87.186.224.178) 7.751 ms 7.987 ms 7.762 ms
3 217.0.85.54 (217.0.85.54) 9.935 ms 12.097 ms 11.373 ms
4 k-ea4-i.K.DE.NET.DTAG.DE (217.5.73.10) 20.915 ms 20.651 ms 20.534 ms
5 62.156.128.10 (62.156.128.10) 17.801 ms 18.224 ms 18.409 ms
6 core-pg1-t13.netcologne.de (87.79.16.29) 17.534 ms 17.757 ms 17.624 ms
7 core-eup2-t41.netcologne.de (87.79.16.205) 19.184 ms 18.974 ms 19.540 ms
8 sixxs-pop1.netcologne.net (78.35.24.124) 17.796 ms 17.812 ms 17.811 ms
I can see outgoing UDP packets but I cannot see any incoming. I also sniffed on the outside of my external legacy-IP router to rule out any NAT or similar issues and clearly showing no single incoming packet from decgn01 78.35.24.124 when aiccu is up. uschi01 still works fine it seems the issue is limited to decgn01.
Tunnel here is T34729.
Tunbel does not work more
And also for you: Please read that big yellow/orange box which is there for a reason, and provide the requested details.
Tunbel does not work more
Shadow Hawkins on Monday, 04 July 2011 17:02:32
Let me correct that. There are actually replies from the IP but the ports are wrong thus hadn't matched the "flow":
14:51:03.908715 IP 93.246.119.88.23207 > 78.35.24.124.5072: UDP, length 100
14:51:03.908715 IP 93.246.119.88.23207 > 78.35.24.124.5072: UDP, length 108
14:51:03.928715 IP 78.35.24.124.5072 > 93.246.119.88.42842: UDP, length 100
14:51:04.908715 IP 93.246.119.88.23207 > 78.35.24.124.5072: UDP, length 100
14:51:04.928715 IP 78.35.24.124.5072 > 93.246.119.88.42842: UDP, length 100
14:51:05.538715 IP 78.35.24.124.5072 > 93.246.119.88.42842: UDP, length 220
14:51:05.908715 IP 93.246.119.88.23207 > 78.35.24.124.5072: UDP, length 100
14:51:05.928715 IP 78.35.24.124.5072 > 93.246.119.88.42842: UDP, length 100
Tunbel does not work more
That is quite silly, resolved now. Thanks for providing those details.
Tunbel does not work more
Shadow Hawkins on Tuesday, 05 July 2011 10:25:04
My Problem reapeared at 4:41 CEST and persisted until 8:36.
Since 10:20 CEST I'm expiriencing trouble again.
Tunbel does not work more
I would say, as you are not providing any details at all, that it is broken or something... is it really that hard to provide even a little bit of information?
Tunbel does not work more
Shadow Hawkins on Tuesday, 05 July 2011 11:02:00
The Symptoms were the the same as yesterday. Therefore I posted to the same ticket as I did yesterday. I did answer as much questions as I coud yesterday.
The only thing I could not check is wheter the answers of the POP are directed to a wrong UDP port, because I can not gather that kind of information from my providers nating CPE.
The Problem disapeared at 10:32 CEST
Tunbel does not work more
Stating that something is broken is not useful and does not help in anyway in determining what, if anything, might be broken. That is why we ask one to collect as much information as possible, as without it we are unable to determine the cause of said brokeness, and without that, the problem, if any, won't be able to be resolved either.
Tunbel does not work more
Shadow Hawkins on Monday, 04 July 2011 16:59:34
This is that does not work any moer
###### [6/8] Ping the IPv6 Remote/PoP Inner Tunnel Endpoint (2001:4dd0:ff00:8e0::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 (both IPv4 and IPv6) of course
### If the previous test was succesful then this could be both
### a firewalling and a routing/interface problem
Ping wird ausgefhrt fr 2001:4dd0:ff00:8e0::1 mit 32 Bytes Daten:
Zeitberschreitung der Anforderung.
Zeitberschreitung der Anforderung.
Zeitberschreitung der Anforderung.
Ping-Statistik fr 2001:4dd0:ff00:8e0::1:
Pakete: Gesendet = 3, Empfangen = 0, Verloren = 3
Tunbel does not work more
Unfortunately with those limited details we really can't do anything.
Tunnel T71769 and related subnet not working
Shadow Hawkins on Monday, 04 July 2011 17:04:09
Greetings,
Tunnel T71769, which had previously been successfully set up on my computer, no longer works. Browser IPv6 traffic times out, ping6 doesn't come up with ICMPv6 replies in Wireshark, configuration unchanged from earlier todays when things worked. The tunnel was reported working last time around 14:20 CEST (12:20 UTC) today (July 4th) according to my tunnel info page.
Let's disregard the subnet for now and focus on the tunnel, as I presume it's a consequence of the failing tunnel.
I can reach the PoP via IPv4, AICCU is up and running, aiccu test tests work (before aiccu terminates prematurely).
AICCU 2007.01.15-console-linux by Jeroen Massar
Running on Ubuntu 11.04 amd64 (= x86_64), package version aiccu-20070115-14ubuntu1 from natty/universe. ip6tables are in a more-or-less trivial firewall setup given below, and permits ICMPv6 no matter what.
Tunnel Information for T71769:
POP Id : decgn01
IPv6 Local : 2001:4dd0:ff00:93e::2/64
IPv6 Remote : 2001:4dd0:ff00:93e::1/64
Tunnel Type : ayiya
Adminstate : enabled
Userstate : enabled
I cannot ping6 2001:4dd0:ff00:93e::1, I get no reply. Wireshark reveals the ICMPv6 echo request packets (in AYIYA encapsulation), but no ICMPv6 echo replies. This worked earlier today.
$ ping6 -n 2001:4dd0:ff00:93e::1
PING 2001:4dd0:ff00:93e::1(2001:4dd0:ff00:93e::1) 56 data bytes
^C
--- 2001:4dd0:ff00:93e::1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4005ms
aiccu syslog output, passwords removed:
Jul 4 16:58:39 apollo aiccu[16588]: sock_getline() : "200 SixXS TIC Service on nlhaa01.sixxs.net ready (http://www.sixxs.net)"
Jul 4 16:58:39 apollo aiccu[16588]: sock_printf() : "client TIC/draft-00 AICCU/2007.01.15-console-linux Linux/2.6.38-8-generic"
Jul 4 16:58:39 apollo aiccu[16588]: sock_getline() : "200 Client Identity accepted"
Jul 4 16:58:39 apollo aiccu[16588]: sock_printf() : "get unixtime"
Jul 4 16:58:39 apollo aiccu[16588]: sock_getline() : "200 1309791519"
Jul 4 16:58:39 apollo aiccu[16588]: sock_printf() : "starttls"
Jul 4 16:58:39 apollo aiccu[16588]: sock_getline() : "400 This service is not SSL enabled (yet)"
Jul 4 16:58:39 apollo aiccu[16588]: TIC Server does not support TLS but TLS is not required, continuing
Jul 4 16:58:39 apollo aiccu[16588]: sock_printf() : "username MAL8-SIXXS"
Jul 4 16:58:39 apollo aiccu[16588]: sock_getline() : "200 MAL8-SIXXS choose your authentication challenge please"
Jul 4 16:58:39 apollo aiccu[16588]: sock_printf() : "challenge md5"
Jul 4 16:58:39 apollo aiccu[16588]: sock_getline() : "200 56be3eb69a153c45bef24fca54ea9c57"
Jul 4 16:58:39 apollo aiccu[16588]: sock_printf() : "authenticate md5 (REMOVED)"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "200 Successfully logged in using md5 as MAL8-SIXXS (Matthias Andree)"
Jul 4 16:58:40 apollo aiccu[16588]: sock_printf() : "tunnel show T71769"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "201 Showing tunnel information for T71769"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "TunnelId: T71769"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "Type: ayiya"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "IPv6 Endpoint: 2001:4dd0:ff00:93e::2"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "IPv6 POP: 2001:4dd0:ff00:93e::1"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "IPv6 PrefixLength: 64"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "Tunnel MTU: 1280"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "Tunnel Name: My First Tunnel"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "POP Id: decgn01"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "IPv4 Endpoint: ayiya"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "IPv4 POP: 78.35.24.124"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "UserState: enabled"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "AdminState: enabled"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "Password: fde169605068498886dcc553d0ddadb3"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "Heartbeat_Interval: 60"
Jul 4 16:58:40 apollo aiccu[16588]: sock_getline() : "202 Done"
Jul 4 16:58:40 apollo aiccu[16588]: Successfully retrieved tunnel information for T71769
Jul 4 16:58:40 apollo aiccu[16588]: sock_printf() : "QUIT I'll be back. Ha, you didn't know I was going to say that!"
Jul 4 16:58:40 apollo aiccu[16596]: AICCU running as PID 16596
Jul 4 16:58:40 apollo aiccu[16596]: [AYIYA-start] : Anything in Anything (draft-02)
Jul 4 16:58:40 apollo aiccu[16596]: [AYIYA-tun->tundev] : (Socket to TUN) started
Firewall config (not showing subnet-related rules):
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT icmpv6 ::/0 ::/0
ACCEPT all ::/0 ::/0
ACCEPT all ::/0 ::/0
DROP all ::/0 ::/0 rt type:0
ACCEPT all fe80::/10 ::/0
ACCEPT all ff00::/8 ::/0
ACCEPT all ::/0 ::/0 state RELATED,ESTABLISHED
Chain FORWARD (policy DROP)
target prot opt source destination
ACCEPT icmpv6 ::/0 ::/0
ACCEPT tcp ::/0 ::/0 tcp dpt:22
DROP all ::/0 ::/0 rt type:0
ACCEPT all ::/0 ::/0 state RELATED,ESTABLISHED
Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT icmpv6 ::/0 ::/0
ACCEPT all ::/0 ::/0
ACCEPT all ::/0 ::/0
ACCEPT all ::/0 ::/0
DROP all ::/0 ::/0 rt type:0
ACCEPT all fe80::/10 ::/0
ACCEPT all ff00::/8 ::/0
Matthias Andree - handle: MAL8-SIXXS
State change: user
The state of this ticket has been changed to user
State change: resolved
The state of this ticket has been changed to resolved
|
![[ch]](/s/countries/ch.gif)
on Sunday, 03 July 2011 10:00:14
Posting is only allowed when you are