netdev - Re: How to make stack send broadcast ARP request when entry is STALE?

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] [day] [month] [year] [list]
Message-Id: <DDC2A17E-E6C7-4F78-B93D-77D199F411AE@emagii.com>
Date:	Wed, 12 Nov 2014 09:46:50 +0100
From:	Ulf samuelsson <netdev@...gii.com>
To:	Brian Haley <brian.haley@...com>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: How to make stack send broadcast ARP request when entry is STALE?



> 11 nov 2014 kl. 17:36 skrev Brian Haley <brian.haley@...com>:
> 
>> On 11/11/2014 05:08 AM, Ulf samuelsson wrote:
>> If I set ucast_solicit to '0', then I always send broadcast, which is not desirable.
> 
> That seems to contradict your statement:
> 
> "The HP router is configured by a customer, and they intentionally limit replies
> to broadcast, and that is how they want it."
> 

The equipment is beeing used in multiple locations, and this is but one.
Normally you want to follow IPv6 rules which says

* Start w broadcast
* Once reply arrives, start using unicast
* If unicast fails for 'ucast_probes', send up to 'mcast_probes' packets before FAIL.
* A reply to a broadcast packet will make the kernel revert to unicast


> So I'm not understanding your question.
> 
> The best way forward would be for you to send a patch out that gets your desired
> behaviour, and let others give feedback on it.
> 
> -Brian



Best Regards
Ulf Samuelsson



> 
>> In the PROBE state of the ARP state machine, "probes" count from 0 .. ucast_probes.
>> 
>> I can see the following arguments for letting "probes" count from 
>> 
>>   0.. (ucast_probes + app_probes + mcast_probes)
>> 
>> 
>> A: This is how the IPv6 is doing it. 
>>     It is not standardized in IPv4, but why should the IPv4 have a different behaviour?
>> 
>> B: If you do not send out broadcast if unicast fails, then a broadcast will be sent out 
>>     anyway, once the ARP entry is removed by the garbage collector.
>>     You get an annoyingly long delay before that happens.
>> 
>> C: If a large data centre does not want broadcasts to be sent out, 
>>     then they can set mcast_probes to 0, in which case no broadcasts will be sent
>>     out in PROBE state.
>> 
>> D:  When in other states, the counter runs until it a reply is had, or the counter wraps around.
>>      It is sending broadcast all the time.
>> 
>> 
>> Best Regards
>> Ulf Samuelsson
>> ulf@...gii.com
>> +46  (722) 427 437
>> 
>> 
>>>> 10 nov 2014 kl. 23:52 skrev Brian Haley <brian.haley@...com>:
>>>> 
>>>> On 11/07/2014 05:11 AM, Ulf samuelsson wrote:
>>>> The HP router is configured by a customer, and they intentionally limit replies
>>>> to broadcast, and that is how they want it.
>>> 
>>> So this is the crux of the problem - the customer has configured the router so
>>> that it doesn't play well with most modern network stacks that try and use
>>> unicast so they don't send unnecessary broadcast packets.  I don't know why I
>>> thought this was something wrong with the router software.
>>> 
>>> Did you try this?
>>> 
>>> $ sudo sysctl net.ipv4.neigh.eth0.ucast_solicit=0
>>> 
>>> It works for me.
>>> 
>>> And they really should re-think their decision on that configuration setting.
>>> 
>>> -Brian
>>> 
>>> 
>>>> In the previous version of the build system, the Interpeak stack was used
>>>> and this would in PROBE state send unicast ARP request, and if that failed
>>>> send broadcast ARP.
>>>> 
>>>> The native linux stack, when in PROBE state sends only unicast until it decides
>>>> that it should enter FAILED state.
>>>> 
>>>> The 'mcast_probes' variable seems to be totally ignored, except the first  time,
>>>> so I do not see why it is there.
>>>> 
>>>> Best Regards
>>>> Ulf Samuelsson
>>>> ulf@...gii.com
>>>> +46  (722) 427 437
>>>> 
>>>> 
>>>>>> 7 nov 2014 kl. 10:54 skrev Brian Haley <brian.haley@...com>:
>>>>>> 
>>>>>> On 11/05/2014 07:48 AM, Ulf samuelsson wrote:
>>>>>> Have a problem with an HP router at a certain location, which
>>>>>> is configured to only answer to broadcast ARP requests.
>>>>>> That cannot be changed.
>>>>> 
>>>>> Sorry to hear about the problem, but my only suggestions would be to try the latest firmware and/or put a call in to support.  I don't happen work in the division that makes routers...
>>>>> 
>>>>>> The first ARP request the kernel sends out, is a broadcast request,
>>>>>> which is fine, but after the reply, the kernel sends unicast requests,
>>>>>> which will not get any replies.
>>>>> 
>>>>> You might be able to hack this by inserting an ebtables rule - check the dnat target section of the man page - don't know the exact syntax but it would probably end in '-j dnat --to-destination ff:ff:ff:ff:ff:ff'
>>>>> 
>>>>> -Brian
>>>>> --
>>>>> 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
>>>> --
>>>> 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
> 
--
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