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 linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 12 Dec 2013 02:21:15 +0100 From: Hannes Frederic Sowa <hannes@...essinduktion.org> To: Michal Kubecek <mkubecek@...e.cz> Cc: Jiri Benc <jbenc@...hat.com>, netdev@...r.kernel.org, Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org> Subject: Re: [PATCH v2 net-next] ipv6: router reachability probing On Thu, Dec 12, 2013 at 12:12:36AM +0100, Michal Kubecek wrote: > On Wed, Dec 11, 2013 at 01:48:20PM +0100, Jiri Benc wrote: > > RFC 4191 states in 3.5: > > > > When a host avoids using any non-reachable router X and instead sends > > a data packet to another router Y, and the host would have used > > router X if router X were reachable, then the host SHOULD probe each > > such router X's reachability by sending a single Neighbor > > Solicitation to that router's address. A host MUST NOT probe a > > router's reachability in the absence of useful traffic that the host > > would have sent to the router if it were reachable. In any case, > > these probes MUST be rate-limited to no more than one per minute per > > router. > > > > Currently, when the neighbour corresponding to a router falls into > > NUD_FAILED, it's never considered again. > > Is it really the case in current mainline kernels? In my tests, this > behaviour in 3.0 kernel (SLES 11 SP3) was caused by the reference held > by struct dst_entry which caused that in neigh_periodic_work(), > n->refcnt was always bigger than one so that the neighbour entry was > never cleaned up. But when I tested with 3.11.6 (OpenSuSE 13.1) where > neighbour is no longer cached in struct dst_entry, the neighbour was > cleaned up eventually and new lookup was performed. IMHO the wording is a big too strong. The *particular* neighbour is never considered again as long as it survives in the NUD_FAILED state (depending on the state of the reference counter this could be between base_reachable_time and infinity in case of bugs ;) ). But probing should happen at least every 60 seconds (or router_probe_interval), which did not happen before this patch. > I believe the patch would be useful anyway as it would speed up the > detection that the router is reachable again, I just want to make sure > my analysis wasn't completely wrong. Yeah, I think your analysis is correct. Also you can see that (at least) I did not considered this worth for -stable but only for net-next. ;) Greetings, Hannes -- 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