netdev - Re: [PATCH v2 net-next] ipv6: router reachability probing

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Dec 2013 00:12:36 +0100
From:	Michal Kubecek <mkubecek@...e.cz>
To:	Jiri Benc <jbenc@...hat.com>
Cc:	netdev@...r.kernel.org,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH v2 net-next] ipv6: router reachability probing

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.

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.

                                                        Michal Kubecek

--
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