lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 17 Apr 2007 20:00:38 -0700 From: Andrew Morton <akpm@...ux-foundation.org> To: netdev@...r.kernel.org Cc: yoshfuji@...ux-ipv6.org, linkfanel@...oo.fr, "bugme-daemon@...nel-bugs.osdl.org" <bugme-daemon@...zilla.kernel.org> Subject: Re: [Bugme-new] [Bug 8349] New: Manually set IPv6 default route ignored On Tue, 17 Apr 2007 18:45:12 -0700 bugme-daemon@...zilla.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@...ux-ipv6.org > Submitter: linkfanel@...oo.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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists