Bug 8349 - Manually set IPv6 default route ignored
Summary: Manually set IPv6 default route ignored
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-17 18:45 UTC by Pierre Ynard
Modified: 2007-06-11 21:16 UTC (History)
2 users (show)

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


Attachments

Description Pierre Ynard 2007-04-17 18:45:08 UTC
Most recent kernel where this bug did *NOT* occur: 2.6.19.5
Distribution: Debian sid
Hardware Environment: x86 (Pentium 4/MMX)
Software Environment: iproute2-ss060323, ifupdown 0.6.8

Problem Description:
Default routes added to the IPv6 routing table, which are not coming from
autoconfiguration, seem to be ignored. Subsequently, IPv6 routing is disrupted,
and for instance calls to connect() fail with an ENETUNREACH error.

Steps to reproduce:
0. Find an IPv6-enabled box on an IPv6-free network. In the absence of any other
configuration, the routing table contains the single line:
fe80::/64 dev eth0 ...
1. Add a default route:
ip -6 ro add default via fe80::1 dev eth0
2. Try to do IPv6, for instance:
# ping6 2001:4978:1:110:0:ac:ce55:1b1e
connect: Network is unreachable
(returns instantly, no packet is sent)

This bug is present in the last stable 2.6.20.7 kernel, and in 2.6.21-rc7. I
actually came across this bug on a server on a network where IPv6 is routed and
advertised, but with autoconfiguration disabled on this server. It *seems* to me
that if the interface is brought up with accept_ra enabled, default routes,
including the one got from RA and ones input by hand later will work, whereas if
it is brought up with accept_ra disabled (or no RA is received), the problem
will occur. Note that routes with a non-null prefix length, such as 3 or 1, work
fine.
Comment 1 Anonymous Emailer 2007-04-17 20:00:41 UTC
Reply-To: akpm@linux-foundation.org

On Tue, 17 Apr 2007 18:45:12 -0700 bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=8349
> 
>            Summary: Manually set IPv6 default route ignored
>     Kernel Version: 2.6.20.7
>             Status: NEW
>           Severity: normal
>              Owner: yoshfuji@linux-ipv6.org
>          Submitter: linkfanel@yahoo.fr
> 
> 
> Most recent kernel where this bug did *NOT* occur: 2.6.19.5
> Distribution: Debian sid
> Hardware Environment: x86 (Pentium 4/MMX)
> Software Environment: iproute2-ss060323, ifupdown 0.6.8
> 
> Problem Description:
> Default routes added to the IPv6 routing table, which are not coming from
> autoconfiguration, seem to be ignored. Subsequently, IPv6 routing is disrupted,
> and for instance calls to connect() fail with an ENETUNREACH error.
> 
> Steps to reproduce:
> 0. Find an IPv6-enabled box on an IPv6-free network. In the absence of any other
> configuration, the routing table contains the single line:
> fe80::/64 dev eth0 ...
> 1. Add a default route:
> ip -6 ro add default via fe80::1 dev eth0
> 2. Try to do IPv6, for instance:
> # ping6 2001:4978:1:110:0:ac:ce55:1b1e
> connect: Network is unreachable
> (returns instantly, no packet is sent)
> 
> This bug is present in the last stable 2.6.20.7 kernel, and in 2.6.21-rc7. I
> actually came across this bug on a server on a network where IPv6 is routed and
> advertised, but with autoconfiguration disabled on this server. It *seems* to me
> that if the interface is brought up with accept_ra enabled, default routes,
> including the one got from RA and ones input by hand later will work, whereas if
> it is brought up with accept_ra disabled (or no RA is received), the problem
> will occur. Note that routes with a non-null prefix length, such as 3 or 1, work
> fine.

Comment 2 Bernhard Schmidt 2007-05-25 06:50:23 UTC
Verified for 2.6.21.3, a box connected to a network segment with two IPv6
routers (both with no router advertisements) which is learning a default route
with Quagga/RIPngd fails to use the default route installed into the kernel by
quagga.

svr02:~# ip -6 route
[...]
default via fe80::20c:86ff:fe9a:3819 dev vlan15  proto zebra  metric 2  expires
21334056sec mtu 1500 advmss 1440 hoplimit 4294967295
svr02:~# ping6 2001:a60:f001:1:218:f3ff:fe66:c777
connect: Network is unreachable
svr02:~# ip -6 route add 2000::/3 via fe80::20c:86ff:fe9a:3819 dev vlan15
svr02:~# ping6 2001:a60:f001:1:218:f3ff:fe66:c777
PING 2001:a60:f001:1:218:f3ff:fe66:c777(2001:a60:f001:1:218:f3ff:fe66:c777) 56
data bytes
64 bytes from 2001:a60:f001:1:218:f3ff:fe66:c777: icmp_seq=1 ttl=59 time=7.67 ms
Comment 3 Bernhard Schmidt 2007-05-28 07:53:48 UTC
According to various reports on IRC and other channels, 2.6.20.1 and 2.6.20.3
work fine, according to the original bugreport 2.6.20.7 is broken.

There is a rather large patch to net/ipv6/route.c for 2.6.20.5, which might be
causing this regression.

http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fincr%2Fpatch-2.6.20.4-5.bz2;z=53

I can't really tell whether the problem is caused by this patch, but it looks
like a good candidate to me.

Pierre, since that bug affects several people and it is a regression (introduced
 in -stable and apparently still in the wild), could you please raise the severity?

Thanks,
Bernhard
Comment 4 Hideaki YOSHIFUJI 2007-05-28 08:23:49 UTC
No, it is not appropriate to raise the severity just because it is a regression
in -stable.
Comment 5 Simon Arlott 2007-05-28 10:04:03 UTC
This bug exists in 2.6.21 too.
Comment 6 Simon Arlott 2007-05-28 15:36:49 UTC
The patch[1] which causes this to break is being debugged in this thread:
http://lkml.org/lkml/2007/5/28/299

1. commit f11e6659ce9058928d73ff440f9b40a818d628ab [IPV6]: Fix routing
round-robin locking.
Comment 7 Pierre Ynard 2007-06-11 18:23:21 UTC
The commit

commit b407fdbabb6c630660e1e9c9c2d212a03b746775
Author: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Date:   Wed Jun 6 22:42:58 2007 -0700

    [PATCH] IPV6 ROUTE: No longer handle ::/0 specially.
    
    We do not need to handle ::/0 routes specially any longer.
    This should fix BUG #8349.

did fix it for me. I suggest this bug be closed.

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