Hello,
On Mon, 25 Jul 2016, 吉藤英明 wrote:
> OK, following blocks are "no-op" and we will get same result.
>
> Well, please do not try changing several things at the same time and
> you could say:
>
> if (ladder == neigh->ha && new == NUD_STALE &&
> !(flags & NUD_UPDATE_F_ADMIN))
>
Hi,
2016-07-25 17:13 GMT+09:00 Chunhui He :
>>> The NEIGH_UPDATE_F_WEAK_OVERRIDE is confusing to me, so I choose not to deal
>>> with the flag.
>>
>> IPv6 depends on WEAK_OVERRIDE. Please do not change.
>>
>
> It seems like IPv6 always sets WEAK_OVERRIDE.
>
Yes.
> As Julian said, maybe there is
Hi,
On Mon, 25 Jul 2016 14:20:29 +0900, YOSHIFUJI Hideaki/吉藤英明
wrote:
> Hi,
>
> Chunhui He wrote:
>> Hi,
>>
>> On Fri, 22 Jul 2016 10:20:01 +0300 (EEST), Julian Anastasov
>> wrote:
>>>
>>> Hello,
>>>
>>> On Thu, 21 Jul 2016, Chunhui He wrote:
>>>
If neigh entry was CONNECTED and addr
Hello,
On Sat, 23 Jul 2016 22:09:43 +0300 (EEST), Julian Anastasov wrote:
>
> May be that is the problem: we receive such packet,
> ip_route_input_noref detects that we allow such packet
> from NEIGH_IP on this interface, tip is not RTN_LOCAL (no
> ARP reply from us), tip is RTN_UNICAST b
Hi,
Chunhui He wrote:
> Hi,
>
> On Fri, 22 Jul 2016 10:20:01 +0300 (EEST), Julian Anastasov
> wrote:
>>
>> Hello,
>>
>> On Thu, 21 Jul 2016, Chunhui He wrote:
>>
>>> If neigh entry was CONNECTED and address is not changed, and if new state is
>>> STALE, entry state will not change. Because
Hello,
On Sat, 23 Jul 2016, Chunhui He wrote:
> The neigh system is to reduce ARP traffic, that is good. The problem is it
> fails
> to handle some coner cases.
>
> The coner case is (let's forget my case above):
> In NUD_DELAY, the neigh system is waiting for a proof of reachablity. I
Hello, Julian.
My case is special, so I think the detail(provided below, if you are intresting)
is not very important. *It only trigers the real problem*.
The neigh system is to reduce ARP traffic, that is good. The problem is it fails
to handle some coner cases.
The coner case is (let's forget
Hello,
On Sat, 23 Jul 2016, Chunhui He wrote:
> On Sat, 23 Jul 2016 09:17:59 +0300 (EEST), Julian Anastasov
> wrote:
> >
> > What kind of problem is this? Remote host wants to
> > see a recent probe from us, otherwise it refuses to resolve
> > our address before its traffic to us
On Sat, 23 Jul 2016 09:17:59 +0300 (EEST), Julian Anastasov wrote:
>
> In my case, the gateway refuses to send unicast packets to me, before it sees
> my ARP request. So it's critical to enter REACHABLE state by sending ARP
> request, but not by external confirmation.
>
>
> What kind of
Hello,
On Fri, 22 Jul 2016, Chunhui He wrote:
> The origin code allows NUD_DELAY -> NUD_STALE and NUD_PROBE -> NUD_STALE.
> This part was imported to kernel since v2.1.79, I don't know clearly why it
> allows that.
>
> My analysis:
> (1) As shown in my previous mail, NUD_DELAY -> NUD_ST
Hi,
On Fri, 22 Jul 2016 10:20:01 +0300 (EEST), Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 21 Jul 2016, Chunhui He wrote:
>
>> If neigh entry was CONNECTED and address is not changed, and if new state is
>> STALE, entry state will not change. Because DELAY is not in CONNECTED, it's
>>
On 22.07.2016 09:20, Julian Anastasov wrote:
>
> Hello,
>
> On Thu, 21 Jul 2016, Chunhui He wrote:
>
>> If neigh entry was CONNECTED and address is not changed, and if new state is
>> STALE, entry state will not change. Because DELAY is not in CONNECTED, it's
>> possible to change state fr
Hello,
On Thu, 21 Jul 2016, Chunhui He wrote:
> If neigh entry was CONNECTED and address is not changed, and if new state is
> STALE, entry state will not change. Because DELAY is not in CONNECTED, it's
> possible to change state from DELAY to STALE.
>
> That is bad. Consider a host in
If neigh entry was CONNECTED and address is not changed, and if new state is
STALE, entry state will not change. Because DELAY is not in CONNECTED, it's
possible to change state from DELAY to STALE.
That is bad. Consider a host in IPv4 nerwork, a neigh entry in STALE state
is referenced to send pa
14 matches
Mail list logo
