|
The 100% loss problem
![[de]](/s/countries/de.gif) Shadow Hawkins on Monday, 26 November 2012 15:11:14
Hi!
I have the problem with my tunnel (aiccu and radvd on a box in my LAN), that the uptime is shown as "0 days", but it is running and working. So I read a lot at the forums, and it seems to be an firewall issue. I also read http://www.sixxs.net/faq/connectivity/?faq=conntracking . As far as I know, the uptime is measured with an ICMP6 echo request.
To test this, I did this on my IPv6-gateway for my LAN:
tcpdump -ni sixxs icmp6
tcpdump: WARNING: sixxs: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
15:54:21.826088 IP6 2001:4dd0:ff00:1083::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 6391, length 988
15:55:20.843784 IP6 2001:4dd0:ff00:1083::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 6392, length 988
15:56:19.863187 IP6 2001:4dd0:ff00:1083::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 6393, length 988
So, there is no reply. But searching for the problem I used this service here:
http://www.subnetonline.com/pages/ipv6-network-tools/online-ipv6-ping.php
If it is an firewall problem, this should not work (this is what I suspect).
But I get:
15:53:54.409231 IP6 2a02:348:82:cb69::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 0, length 40
15:53:54.409285 IP6 2001:4dd0:ff00:1083::2 > 2a02:348:82:cb69::1: ICMP6, echo reply, seq 0, length 40
15:53:55.414002 IP6 2a02:348:82:cb69::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 1, length 40
15:53:55.414047 IP6 2001:4dd0:ff00:1083::2 > 2a02:348:82:cb69::1: ICMP6, echo reply, seq 1, length 40
15:53:56.418748 IP6 2a02:348:82:cb69::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 2, length 40
15:53:56.418794 IP6 2001:4dd0:ff00:1083::2 > 2a02:348:82:cb69::1: ICMP6, echo reply, seq 2, length 40
15:53:57.425812 IP6 2a02:348:82:cb69::1 > 2001:4dd0:ff00:1083::2: ICMP6, echo request, seq 3, length 40
15:53:57.425890 IP6 2001:4dd0:ff00:1083::2 > 2a02:348:82:cb69::1: ICMP6, echo reply, seq 3, length 40
So, this works. I have no idea what is happening here. Please tell me what information I can provide to help identify the problem.
The 100% loss problem
tcpdump -ni sixxs icmp6
It seems more that your IPv6 stack is not replying to these request at all. That indicates that it is likely your IPv6 firewall... and/or you have your routes misconfigured.
If it is an firewall problem, this should not work (this is what I suspect).
Depends on your firewall, but as above check routes too...
The 100% loss problem
Shadow Hawkins on Monday, 26 November 2012 15:25:51
Thanks for your quick reply!
It seems more that your IPv6 stack is not replying to these request at all. That indicates that it is likely your IPv6 firewall
But why is the other ping working? I do not understand this (to be fair, I am rather new to this topic). I also just checked disabling my firewall, same results.
but as above check routes too...
How can I do this? My system is a debian box, running behind NAT.
The 100% loss problem
But why is the other ping working? I do not understand this (to be fair, I am rather new to this topic). I also just checked disabling my firewall, same results.
Because when something is misconfigured then things might break in weird ways ;)
How can I do this? My system is a debian box, running behind NAT.
With:
ip -6 ro show
and of course you want to check all friends of that commands:
ip -6 addr show
ip -6 nei show
etc...
The 100% loss problem
Shadow Hawkins on Monday, 26 November 2012 16:04:22
Ok:
ip -6 ro show
2001:4dd0:ff00:1083::/64 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295
2001:4dd0:ff00:1083::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
2001:4dd0:ff00:9083::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295
default via 2001:4dd0:ff00:1083::1 dev sixxs metric 1024 mtu 1280 advmss 1220 hoplimit 4294967295
and:
ip -6 addr show
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:ff00:9083::1/64 scope global
valid_lft forever preferred_lft forever
inet6 2001:4dd0:ff00:1083::1/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::a00:27ff:fe87:5385/64 scope link
valid_lft forever preferred_lft forever
8: sixxs: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qlen 500
inet6 2001:4dd0:ff00:1083::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::4cd0:ff00:1083:2/64 scope link
valid_lft forever preferred_lft forever
ip -6 nei show does not seem to have any output.
Can you see any problem? Because for me, I do not see the problem.
The 100% loss problem
Shadow Hawkins on Monday, 26 November 2012 16:05:48
Oh, sorry. I made a mistake with the code tags :(
The 100% loss problem
2001:4dd0:ff00:1083::/64 dev sixxs proto kernel metric 256 mtu 1280 advmss 1220 hoplimit 4294967295 2001:4dd0:ff00:1083::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
Why do you route the tunnel prefix to both 'sixxs' (the tunnel) and 'eth0' (your local network) ?
This is what causes the packets to not be sent back correctly, and why your pings are not being sent back over the 'sixxs' interface.
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000 [..]
inet6 2001:4dd0:ff00:1083::1/64 scope global valid_lft forever preferred_lft forever
Even worse, you have here the IPv6 address of the PoP-side of the tunnel on your own machine. And that is why you never reply to the PoP as those packets end up on your machine.
The 100% loss problem
Shadow Hawkins on Monday, 26 November 2012 16:14:27
Now I get it. Thanks. This was not intended. I followed some tutorials to set up this. I hope I get it fixed on my own.
Thanks again for helping the noob :)
The 100% loss problem
Check /etc/network/interface where it likely is.
And to quickly get rid of it:
ip -6 addr del 2001:4dd0:ff00:1083::1/64 dev eth0
Note that whatever put it there though might put it back hence the check for this in the interfaces file.
The 100% loss problem
Shadow Hawkins on Monday, 26 November 2012 16:22:44
I deleted it already. Now it seems to work. I am only waiting for the graph at my tunnel website.
Thanks again!
The 100% loss problem
Shadow Hawkins on Monday, 26 November 2012 17:13:29
It works!
|
![[ch]](/s/countries/ch.gif)
on Monday, 26 November 2012 15:15:31
Posting is only allowed when you are