netdev - Re: [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE state

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]

Message-ID: <5506CF13.5070501@ericsson.com>
Date:	Mon, 16 Mar 2015 13:39:47 +0100
From:	Ulf Samuelsson <ulf.samuelsson@...csson.com>
To:	David Miller <davem@...hat.com>, <Yanjun.Zhu@...driver.com>
CC:	<brian.haley@...com>, <alexandre.dietsch@...driver.com>,
	<clinton.slabbert@...driver.com>, <kuznet@....inr.ac.ru>,
	<jmorris@...ei.org>, <kaber@...sh.net>, <netdev@...r.kernel.org>
Subject: Re: [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE
 state

On 03/12/2015 08:22 PM, David Miller wrote:
> Like Yoshifuji and others I agree that:
>
> 1) You can get working behavior by adjusting existing sysctls.
>
> 2) IPV4 ARP and IPV6 NDISC are not different in this regard.
>
> I'm really tired of all of these ARP hacks being submitted recently,
> and I want people to think more deeply about what they are proposing
> first.
Which sysctls are you referring to?

As I can see it, there are three sysctls that control this.

ucast_solicit.
mcast_solicit
app_solicit.

If you think any other sysctl is useful here, which one?

 From Documentation/networking/ip-sysctl.txt.
+++++++++++++
app_solicit - INTEGER
     The maximum number of probes to send to the user space ARP daemon
     via netlink before dropping back to multicast probes (see
     mcast_solicit).  Defaults to 0.
----------------------------
so that ain't it.
If you disagree, what should the Documentation look like?

=============================================
 From net/core/neighbour.c(timer_handler):

     if ((neigh->nud_state & (NUD_INCOMPLETE | NUD_PROBE)) &&
         atomic_read(&neigh->probes) >= neigh_max_probes(neigh)) {
         neigh->nud_state = NUD_FAILED;
         notify = 1;
         neigh_invalidate(neigh);
         goto out;
     }

 From net/core/neighbour.c(neigh_max_probes):
static __inline__ int neigh_max_probes(struct neighbour *n)
{
     struct neigh_parms *p = n->parms;
     int max_probes = NEIGH_VAR(p, UCAST_PROBES) + NEIGH_VAR(p, APP_PROBES);
     if (!(n->nud_state & NUD_PROBE))
         max_probes += NEIGH_VAR(p, MCAST_PROBES);
     return max_probes;
}
=============================================


If we simplify this when we are in NUD_PROBE state we see:

=============================================
     if (atomic_read(&neigh->probes) >= NEIGH_VAR(p, UCAST_PROBES) + 
NEIGH_VAR(p, APP_PROBES)) {
         neigh->nud_state = NUD_FAILED;
         notify = 1;
         neigh_invalidate(neigh);
         goto out;
     }
=============================================

Since APP_PROBES is 0, and according to documentation has nothing to do 
with Broadcast:

=============================================
     if (atomic_read(&neigh->probes) >= NEIGH_VAR(p, UCAST_PROBES)) {
         neigh->nud_state = NUD_FAILED;
         notify = 1;
         neigh_invalidate(neigh);
         goto out;
     }
=============================================

so we will send out "ucast_solicit" unikcast probes, and then we will 
enter FAILED state.
mcast_solicit is ignored when in NUD_PROBE state.

"mcast_solicit" is only used when in NUD_INCOMPLETE state, and 
broadcasts will never
be sent out by the stack for an entry, once it is in NUD_REACHABLE for 
the first time.

I would be happy, if you can show me that I have misunderstood something.

Best Regards,
Ulf Samuelsson

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