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.
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.
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
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
No, it is not appropriate to raise the severity just because it is a regression in -stable.
This bug exists in 2.6.21 too.
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.
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.