Bug 8382

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