[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <55015C3E.9060009@miraclelinux.com>
Date: Thu, 12 Mar 2015 18:28:30 +0900
From: YOSHIFUJI Hideaki/吉藤英明
<hideaki.yoshifuji@...aclelinux.com>
To: Ulf samuelsson <netdev@...gii.com>
CC: hideaki.yoshifuji@...aclelinux.com,
yzhu1 <Yanjun.Zhu@...driver.com>,
"brian.haley@...com" <brian.haley@...com>,
"davem@...emloft.net" <davem@...emloft.net>,
"alexandre.dietsch@...driver.com" <alexandre.dietsch@...driver.com>,
"clinton.slabbert@...driver.com" <clinton.slabbert@...driver.com>,
"kuznet@....inr.ac.ru" <kuznet@....inr.ac.ru>,
"jmorris@...ei.org" <jmorris@...ei.org>,
"kaber@...sh.net" <kaber@...sh.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ulf.samuelsson@...csson.com" <ulf.samuelsson@...csson.com>,
"YOSHIFUJI Hideaki (USAGI Project)" <yoshfuji@...ux-ipv6.org>
Subject: Re: [PATCH V2 0/1] neighbour: Support broadcast ARP in neighbor PROPE
state
Hi,
Ulf samuelsson wrote:
> That also means that you increase the number of broadcasts in incomplete state.
> Is that really desirable?
In NUD_INCOMPLETE state, neighbour subsystem *skips* sending unicast probes
and send multicast probes mcast_solicit times. If you do not increase
the number of mcast_solicit, the number of multicast probes in
NUD_INCOMPLETE will not increased.
--yoshfuji
>
> Best Regards
> Ulf Samuelsson
> ulf@...gii.com
> +46 (722) 427 437
>
>
>> 12 mar 2015 kl. 09:42 skrev YOSHIFUJI Hideaki <hideaki.yoshifuji@...aclelinux.com>:
>>
>> Hello.
>>
>> yzhu1 wrote:
>>> The state machine is in the attachment.
>>>
>>> Best Regards!
>>> Zhu Yanjun
>>>> On 03/12/2015 02:58 PM, Zhu Yanjun wrote:
>>>> V2:
>>>> set ARP_PROBE_BCAST default N.
>>>>
>>>> V1:
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>> The ARP entry will after some time enter STALE state,
>>>> and if nothing is done it will time out, and be removed.
>>>> This process takes to long, and I have been told that it is
>>>> difficult to makes changes that will eventually remove it.
>>>>
>>>> Have tried to change the state from STALE to INCOMPLETE, which failed,
>>>> and then tried to change the state to PROBE which also failed.
>>>>
>>>> The stack is only sending out unicasts, and never broadcast.
>>>> Is there any way to get the stack to send out a broadcast ARP
>>>> without having to wait for the entry to be removed?
>>
>> Neighbour subsystem will send multicast probes after unicast
>> probes in NUD_PROBE state if mcast_solicit is more than
>> ucast_solicit. Try setting net.ipv4.neigh.*.ucast_solicit to
>> the value less than net.ipv4.neigh.*.mcast_solicit, please?
>> e.g.
>>
>> net.ipv4.neigh.eth0.mcast_solicit = 3
>> net.ipv4.neigh.eth0.ucast_solicit = 1
>>
>> --yoshfuji
>>
>>
>>>>
>>>> I think the recommended behaviour in IPv6 is to send out 3 unicasts
>>>> and if all fails, to send out broadcasts.
>>>>
>>>> Zhu Yanjun (1):
>>>> neighbour: Support broadcast ARP in neighbor PROPE state
>>>>
>>>> include/net/neighbour.h | 7 ++++++
>>>> include/uapi/linux/neighbour.h | 6 +++++
>>>> include/uapi/linux/sysctl.h | 3 +++
>>>> kernel/sysctl_binary.c | 3 +++
>>>> net/core/neighbour.c | 44 +++++++++++++++++++++++++++++---
>>>> net/ipv4/Kconfig | 57 ++++++++++++++++++++++++++++++++++++++++++
>>>> net/ipv4/arp.c | 7 ++++--
>>>> 7 files changed, 121 insertions(+), 6 deletions(-)
>>
>> --
>> Hideaki Yoshifuji <hideaki.yoshifuji@...aclelinux.com>
>> Technical Division, MIRACLE LINUX CORPORATION
>> --
>> 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
--
吉藤英明 <hideaki.yoshifuji@...aclelinux.com>
ミラクル・リナックス株式会社 技術本部 サポート部
--
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