svn commit: r233773 - head/usr.sbin/arp

[Qing Li]

You missed my points.

That "if" check as part of r201282 was meant to resolve a couple of
issues related
to PPP links, as noted in my commit message. In this PPP/proxy
resolution context
the error message applies, which is why I actually used the word "context" in my
previous reply.

Your removing of that code will break the fixes committed in r201282.

You don't need to try so hard to be pedantic ...

When I say let's put in the code to support RFC 3012 "properly", I
mean exactly that,
i.e., put code in which makes RFC3012 work without breaking the previous fixes.
And if there are other cases we need to cover, well, let's make sure we do.
Do you have another definition of a "proper" fix ?

I can't quite decipher the example you described in this email.

Could you please give me a bit more information in a private email so I can have
a better look at the issue, and possibly make a suggestion for an alternative
patch ?

--Qing


2012/4/8 Gleb Smirnoff <glebius at freebsd.org>:
>  Qing,
>
> On Sun, Apr 08, 2012 at 10:41:11AM -0700, Qing Li wrote:
> Q> This is not the right way to support RFC3021.
> Q>
> Q> The code you removed is used for checking against attempt at adding
> Q> duplicate entry.
> Q> Both the message and the code apply in that context. I tried to state
> Q> clearly and concisely
> Q> what r201282 was intended in solving and was verified by actual users
> Q> who ran into the
> Q> described problems.
>
> How does the message apply?
>
> On a 10.0/9.0 prior to my commit:
>
> #ifconfig em0
> em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>        options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
>        ether f0:de:f1:6c:5b:fa
>        inet x.x.x.111 netmask 0xffffffe0 broadcast x.x.x.127
>        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
>        media: Ethernet autoselect (100baseTX <full-duplex>)
>        status: active
> # arp -an
> ? (x.x.x.97) at 00:00:5e:00:01:61 on em0 expires in 1198 seconds [ethernet]
> ? (x.x.x.101) at 00:e0:81:5a:22:49 on em0 expires in 618 seconds [ethernet]
> ? (x.x.x.111) at f0:de:f1:6c:5b:fa on em0 permanent [ethernet]
> ? (x.x.x.116) at 00:26:18:6a:ea:02 on em0 expires in 1128 seconds [ethernet]
> # # arp -s 81.19.64.96 0:0:0:0:0:0
> set: proxy entry exists for non 802 device
>
> And how does this apply? Where is the proxy entry mentioned? Where is the
> non 802 device?
>
> Look at the code before r201282 and see that the message was for absolutely
> unrelated case.
>
> And here is behavior of 6.1-RELEASE, that is prior to your new ARP work:
>
> # ifconfig fxp0
> fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
>        options=8<VLAN_MTU>
>        inet x.x.x.134 netmask 0xfffffffc broadcast x.x.x.135
>        ether 00:20:ed:6e:9c:f9
>        media: Ethernet autoselect (10baseT/UTP)
>        status: active
> # arp -s x.x.x.132 0:0:0:0:0:0
> set: can only proxy for x.x.x.132
>
> As you see, the error message was an other one.
>
> Q> If we actually need to support RFC 3021, then better do it properly.
>
> What do you mean here under "properly"? RFC3021 says that network address
> in a /31 network is a common address. Thus it should be possible to have
> an ARP entry for it.
>
> Anyway this change isn't about RFC3021. A /31 network is just a case when we
> need to set ARP entry for network address.
>
> --
> Totus tuus, Glebius.