netdev - Re: probe netlink app in NUD

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:	Tue, 25 Feb 2014 18:18:44 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	timo.teras@....fi
Cc:	netdev@...r.kernel.org
Subject: Re: probe netlink app in NUD_PROBE

From: Timo Teras <timo.teras@....fi>
Date: Sat, 22 Feb 2014 10:44:19 +0200

> When a stale or delayed neigh entry is being re-validated the entry
> goes to NUD_PROBE state. At the moment only unicast probes are sent.
> This is basically because neigh_max_probes() limits the probe amount so.
> 
> Now, opennhrp intentionally configures UCAST_PROBES and MCAST_PROBES to
> zero and APP_PROBES to something meaningful. The idea is that opennhrp
> replaces arp completely with NHRP implemented in userland.
> 
> Due to this it seems there is a very small time window, when the
> NUD_PROBE times out and the neighbour entry gets invalidated, and
> packets get lost.
> 
> To remedy this, I would like to have these NUD_PROBE validations sent
> via netlink too.
> 
> First choice is to change to just use both unicast and application
> probes:

So basically, the generic and protocol-specific neighbour code work
together to implement a cascading priority based probing scheme using
a per-neigh counter and three limits.

It seems that neigh->probes is zero when we enter the probing state.

On each solicit we increment neigh->probes.

Then we have this very funny logic in the protocol specific
implementations of solicit:

	probes = atomic_read(&neigh->probes);

	probes -= UCAST_PROBES;
	if (probes < 0) {
		send unicast probe;
	} else {
		probes -= APP_PROBES;
		if (probes < 0) {
			trigger application based probe via netlink
		} else {
			send multicast probe;
		}
	}

As an example, for ipv4 arp, UCAST_PROBES defaults to 3 and APP_PROBES
defaults (as you say) to zero.

If neigh_max_probes() evaluates to UCAST_PROBES, we'll do 3 unicast
probes then fail the neigh, for example.

I took a look at iproute2's arpd, and I suggest you take a gander
over there as well.

If given the '-a N' option it will set app_probes to N and send it's
own ARP requests out in certain situations.

It might depend upon the current behavior of neigh_max_probes().
--
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