Most recent kernel where this bug did *NOT* occur: 2.6.19.7 Distribution: Debian Etch 4.0 Hardware Environment: i386 VIA Samuel 2 700mhz Software Environment: Debian Etch Problem Description: I am using an IPv6 tunnel broker (SixXs) which is using aiccu (dynamic IPv4 address using heartbeat to get in sync with IPv6 tunnel to SixXS). When using 2.6.20.x it doesn't route packets outside the tunnel anymore. This means that from my gateway, i can ping my local interface and my remote one but not a single other IPv6 address. When trying to traceroute or send IPv6 packets from any other machine on my network to an outside IPv6 address, i keep getting a network unreachable message. This was tested against 2.6.20.{5,7,8,9} and also 2.6.19.6/7. It works perfectly on any 2.6.19.x kernel or previous but fails under 2.6.20.x I made a diff in the IPv6 stack between 19 and 20 but my programming skills are clearly lacking :( Steps to reproduce: Compile with IPv6 settings that I am including with this bug report, 2.6.19 works, 2.6.20 doesn't.
Created attachment 11291 [details] kernel configuration for 2.6.19 which works properly
Created attachment 11292 [details] kernel configuration for 2.6.20 which doesn't work
Actually, problem is on a Debian Sarge (3.1) system, but I don't think it does matter a great deal in that context. Steph
2.6.21 seems to also be affected by this issue.
Please bisect. Thank you.
Well, i just wanted to let you know that both 2.6.20 and 2.6.21 suffer from the same issue.
I just saw the release of 2.6.20.10 with the following, is that a fix for the routing issue too ? YOSHIFUJI Hideaki (1): IPV6: Fix for RT0 header ipv6 change.
Hi again, I tested this further, and can confirm that the latest patch does not fix this, here is a diff taken between two ping6 , left is with a working 2.6.19.7 and right is with a non working 2.6.21.1 : < connect(4, {sa_family=AF_INET6, sin6_port=htons(1025), inet_pton(AF_INET6, "2001:770:60:7:206:5bff:fe3e:6c15", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0 < getsockname(4, {sa_family=AF_INET6, sin6_port=htons(2050), inet_pton(AF_INET6, "2001:770:100:14::2", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 < close(4) = 0 --- > connect(4, {sa_family=AF_INET6, sin6_port=htons(1025), inet_pton(AF_INET6, "2001:770:60:7:206:5bff:fe3e:6c15", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 ENETUNREACH (Network is unreachable) > dup(2) = 5 > fcntl64(5, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) The part i think is weird too is the expires time way shorter on 2.6.21.1 which does not work : < 2001:770:100:14::/64 via :: dev sixxs metric 256 expires -98sec mtu 1280 advmss 1220 hoplimit 4294967295 < 2001:770:10e:10::/64 dev eth0 metric 256 expires -111sec mtu 1500 advmss 1220 hoplimit 4294967295 < fe80::/64 via :: dev sixxs metric 256 expires -98sec mtu 1280 advmss 1220 hoplimit 4294967295 < default via 2001:770:100:14::1 dev sixxs metric 1024 expires -98sec mtu 1280 advmss 1220 hoplimit 4294967295 < ff00::/8 dev eth0 metric 256 expires -125sec mtu 1500 advmss 1220 hoplimit 4294967295 < ff00::/8 dev sixxs metric 256 expires -98sec mtu 1280 advmss 1220 hoplimit 4294967295 --- > 2001:770:100:14::/64 via :: dev sixxs metric 256 expires -50sec mtu 1280 advmss 1220 hoplimit 4294967295 > 2001:770:10e:10::/64 dev eth0 metric 256 expires -67sec mtu 1500 advmss 1220 hoplimit 4294967295 > fe80::/64 dev eth0 metric 256 expires -80sec mtu 1500 advmss 1220 hoplimit 4294967295 > fe80::/64 via :: dev sixxs metric 256 expires -49sec mtu 1280 advmss 1220 hoplimit 4294967295 > default via 2001:770:100:14::1 dev sixxs metric 1024 expires -49sec mtu 1280 advmss 1220 hoplimit 4294967295 > ff00::/8 dev eth0 metric 256 expires -80sec mtu 1500 advmss 1220 hoplimit 4294967295 > ff00::/8 dev sixxs metric 256 expires -49sec mtu 1280 advmss 1220 hoplimit 4294967295 Please let me know if there is anything i can do to debug this. Steph
I had the same problem with the same type of tunnel to sixxs. After unchecking IPV6_PRIVACY, IPV6_ROUTER_PREF and IPV6_MULTIPLE_TABLES in 2.6.20.10, it worked again. I didn't track down which of them actually caused the problem, but maybe you want to do this.
Hello, I am dying to compare your configuration file, since mine doesn't work with the 3 options disabled, i still get an unreachable : # CONFIG_IPV6_MULTIPLE_TABLES is not set # CONFIG_IPV6_ROUTER_PREF is not set # CONFIG_IPV6_PRIVACY is not set Funnily enough, in 2.6.19.7, they are and my tunnel and subnet from SixXS work like a charm : CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_PRIVACY=y Here's my modules list : tun 10880 0 sit 10468 0 ip6t_LOG 7296 2 xt_limit 2944 1 ip6table_filter 3204 1 ip6_tables 13528 2 ip6t_LOG,ip6table_filter ipt_MASQUERADE 3840 1 ipt_TCPMSS 4352 1 xt_tcpudp 3712 25 xt_state 2816 9 ipt_LOG 6400 1 iptable_nat 7812 1 iptable_mangle 3200 0 iptable_filter 3332 1 nf_nat_irc 3076 0 nf_conntrack_irc 7716 1 nf_nat_irc nf_nat_ftp 3716 0 nf_nat 17324 4 ipt_MASQUERADE,iptable_nat,nf_nat_irc,nf_nat_ftp nf_conntrack_ftp 9760 1 nf_nat_ftp ip_tables 12504 3 iptable_nat,iptable_mangle,iptable_filter x_tables 14852 10 ip6t_LOG,xt_limit,ip6_tables,ipt_MASQUERADE,ipt_TCPMSS,xt_tcpudp,xt_state,ipt_LOG,iptable_nat,ip_tables
I guess it wouldn't help much. I had to reboot because of a RAM upgrade and now I'm having the same problem again - so it just worked "by accident" last time. This is really very annoying...
When you are saying by accident, are you 100% sure you were running the same kernel ? Because none of the 2.6.20 revisions can change this, this is still not working. This is rather blocking since I will eventually upgrade to 2.6.2x and would like to be able carrying on using IPv6 and my tunnel broker.
I confirm this bug on all the kernels >= 2.6.20. Maybe is something related to the layer 3 indipendent connection tracking? I have to point that the problem here is quite different. Instead breaking all the routes just after the booting process, it happens usually a couple of hours later.
FRLinux, I /AM/ 100% sure I was running exactly the same kernel. It was just a reboot and after that, it stopped working again. This is quite strange. Nevertheless, I'm back to 2.6.19 and I'm happy with that so far :)
[update] ip route add 2000::/3 dev ifname fix the problem. Strange behaviour. Looks like a regression (was this settings suggested only for kernels <2.4.20?)
Well, this workaround is far from being perfect. Every 20 hours more or less I have to delete the added route and then readd it. Weird!....
Point is, that is a legitimate bug which is affecting kernels above 2.6.19 and should definitely be fixed.
2.6.21 fixes some of it, it can now ping ipv6 addresses on the internet. The routing from local net is still broken.
On Fedora 7 with kernel 2.6.21-1 I had a strange behaviour: If a wifi card is installed on the system, the routing seem to work, The wifi card must not be active. with a normal second network card instead of the wifi card the routing don't work.
2.6.21.5 fixed it for me, it can route IPv6 packets the way it used to.
>2.6.21.5 fixed it for me, it can route IPv6 packets the way it used to. not for me! The Bug still exist on my sixxs AYIYA tunnel.
Closing out old stale bugs