Bug 8382 - 2.6.20 cannot route packets outside tunnel
Summary: 2.6.20 cannot route packets outside tunnel
Status: CLOSED CODE_FIX
Alias: None
Product: Networking
Classification: Unclassified
Component: IPV6 (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Hideaki YOSHIFUJI
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-27 16:01 UTC by FRLinux
Modified: 2009-03-23 10:59 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.20.9
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
kernel configuration for 2.6.19 which works properly (42.12 KB, application/octet-stream)
2007-04-27 16:02 UTC, FRLinux
Details
kernel configuration for 2.6.20 which doesn't work (43.18 KB, application/octet-stream)
2007-04-27 16:02 UTC, FRLinux
Details

Description FRLinux 2007-04-27 16:01:01 UTC
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.
Comment 1 FRLinux 2007-04-27 16:02:16 UTC
Created attachment 11291 [details]
kernel configuration for 2.6.19 which works properly
Comment 2 FRLinux 2007-04-27 16:02:54 UTC
Created attachment 11292 [details]
kernel configuration for 2.6.20 which doesn't work
Comment 3 FRLinux 2007-04-27 17:25:06 UTC
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
Comment 4 FRLinux 2007-04-27 18:25:31 UTC
2.6.21 seems to also be affected by this issue.
Comment 5 Hideaki YOSHIFUJI 2007-04-27 18:32:47 UTC
Please bisect.  Thank you.
Comment 6 FRLinux 2007-04-27 18:35:55 UTC
Well, i just wanted to let you know that both 2.6.20 and 2.6.21 suffer from the
same issue.
Comment 7 FRLinux 2007-04-28 10:13:29 UTC
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.

Comment 8 FRLinux 2007-04-30 12:57:18 UTC
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
Comment 9 Felix M. Palmen 2007-04-30 16:08:06 UTC
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.
Comment 10 FRLinux 2007-04-30 17:31:11 UTC
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
Comment 11 Felix M. Palmen 2007-05-08 13:39:50 UTC
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...
Comment 12 FRLinux 2007-05-09 10:40:16 UTC
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.

Comment 13 Stefano Ortolani 2007-05-10 03:05:43 UTC
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.

Comment 14 Felix M. Palmen 2007-05-11 14:59:43 UTC
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 :)
Comment 15 Stefano Ortolani 2007-05-14 12:53:16 UTC
[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?)
Comment 16 Stefano Ortolani 2007-05-17 13:15:18 UTC
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!....
Comment 17 FRLinux 2007-05-17 14:19:01 UTC
Point is, that is a legitimate bug which is affecting kernels above 2.6.19 and
should definitely  be fixed.
Comment 18 FRLinux 2007-05-25 13:28:04 UTC
2.6.21 fixes some of it, it can now ping ipv6 addresses on the internet. 
The routing from local net is still broken.
Comment 19 Jean-Jacques Sarton 2007-06-15 00:20:41 UTC
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.
Comment 20 FRLinux 2007-06-15 00:45:51 UTC
2.6.21.5 fixed it for me, it can route IPv6 packets the way it used to.
Comment 21 Thomas Creutz 2007-06-21 09:26:17 UTC
>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.
Comment 22 Alan 2009-03-23 10:59:33 UTC
Closing out old stale bugs

Note You need to log in before you can comment on or make changes to this bug.