| 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: 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
Powered by blists - more mailing lists