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

2012-04-10 Thread Gleb Smirnoff 
  Qing,

On Mon, Apr 09, 2012 at 02:26:06PM -0700, Qing Li wrote:
Q You missed my points.
Q 
Q That if check as part of r201282 was meant to resolve a couple of
Q issues related
Q to PPP links, as noted in my commit message. In this PPP/proxy
Q resolution context
Q the error message applies, which is why I actually used the word context 
in my
Q previous reply.
Q 
Q Your removing of that code will break the fixes committed in r201282.

Can you please provide example of PPP link configuration, that was
broken by r233773.

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

Okay, here it is more verbose:

My list of interfaces:

# ifconfig -l
em0 wlan0 iwn0 lo0

My only configured interface:

# ifconfig em0
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
       
options=4219bRXCSUM,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 0xffe0 broadcast x.x.x.127
       nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL
       media: Ethernet autoselect (100baseTX full-duplex)
       status: active

My arp table:

# 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]

Now I'm trying to set ARP entry for network address. And I get error:

# arp -s 81.19.64.96 0:0:0:0:0:0
set: proxy entry exists for non 802 device

Questions: where is the proxy entry mentioned in the above ARP table? I don't
see one. Where is the non 802 device in the above list of my interfaces?

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

I have mailed you 8 March 2012 with msg-id 
20120308173642.gw13...@glebius.int.ru,
and didn't got any reply since. That's why I proceeded with commit.

P.S. And please, can you avoid top quoting when discussing on technical FreeBSD
lists? This isn't my personal wish but explicitly documented etiquette:

http://www.freebsd.org/doc/en_US.ISO8859-1/articles/mailing-list-faq/etiquette.html#ETIQUETTE-REPLYING

-- 
Totus tuus, Glebius.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

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

2012-04-09 Thread Gleb Smirnoff 
  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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500

options=4219bRXCSUM,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 0xffe0 broadcast x.x.x.127 
nd6 options=29PERFORMNUD,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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
options=8VLAN_MTU
inet x.x.x.134 netmask 0xfffc 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.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

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

2012-04-09 Thread 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 gleb...@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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
        
 options=4219bRXCSUM,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 0xffe0 broadcast x.x.x.127
        nd6 options=29PERFORMNUD,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=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
        options=8VLAN_MTU
        inet x.x.x.134 netmask 0xfffc 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.
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

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

2012-04-08 Thread Qing Li 
This is not the right way to support RFC3021.

The code you removed is used for checking against attempt at adding
duplicate entry.
Both the message and the code apply in that context. I tried to state
clearly and concisely
what r201282 was intended in solving and was verified by actual users
who ran into the
described problems.

If we actually need to support RFC 3021, then better do it properly.

--Qing


On Mon, Apr 2, 2012 at 3:44 AM, Gleb Smirnoff gleb...@freebsd.org wrote:
 Author: glebius
 Date: Mon Apr  2 10:44:25 2012
 New Revision: 233773
 URL: http://svn.freebsd.org/changeset/base/233773

 Log:
  Historically arp(8) did a route lookup for the entry it is
  about to add, and failed if it exist and had invalid data
  link type.

  Later on, in r201282, this check morphed to other code, but
  message proxy entry exists for non 802 device still left,
  and now it is printed in a case if route prefix found is
  equal to current address being added. In other words, when
  we are trying to add ARP entry for a network address. The
  message is absolutely unrelated and disappointing in this
  case.

  I don't see anything bad with setting ARP entries for
  network addresses. While useless in usual network,
  in a /31 RFC3021 it may be necessary. This, remove this code.

 Modified:
  head/usr.sbin/arp/arp.c

 Modified: head/usr.sbin/arp/arp.c
 ==
 --- head/usr.sbin/arp/arp.c     Mon Apr  2 10:24:50 2012        (r233772)
 +++ head/usr.sbin/arp/arp.c     Mon Apr  2 10:44:25 2012        (r233773)
 @@ -387,10 +387,6 @@ set(int argc, char **argv)
        }
        addr = (struct sockaddr_inarp *)(rtm + 1);
        sdl = (struct sockaddr_dl *)(SA_SIZE(addr) + (char *)addr);
 -       if (addr-sin_addr.s_addr == dst-sin_addr.s_addr) {
 -               printf(set: proxy entry exists for non 802 device\n);
 -               return (1);
 -       }

        if ((sdl-sdl_family != AF_LINK) ||
            (rtm-rtm_flags  RTF_GATEWAY) ||
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org

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

2012-04-02 Thread Gleb Smirnoff 
Author: glebius
Date: Mon Apr  2 10:44:25 2012
New Revision: 233773
URL: http://svn.freebsd.org/changeset/base/233773

Log:
  Historically arp(8) did a route lookup for the entry it is
  about to add, and failed if it exist and had invalid data
  link type.
  
  Later on, in r201282, this check morphed to other code, but
  message proxy entry exists for non 802 device still left,
  and now it is printed in a case if route prefix found is
  equal to current address being added. In other words, when
  we are trying to add ARP entry for a network address. The
  message is absolutely unrelated and disappointing in this
  case.
  
  I don't see anything bad with setting ARP entries for
  network addresses. While useless in usual network,
  in a /31 RFC3021 it may be necessary. This, remove this code.

Modified:
  head/usr.sbin/arp/arp.c

Modified: head/usr.sbin/arp/arp.c
==
--- head/usr.sbin/arp/arp.c Mon Apr  2 10:24:50 2012(r233772)
+++ head/usr.sbin/arp/arp.c Mon Apr  2 10:44:25 2012(r233773)
@@ -387,10 +387,6 @@ set(int argc, char **argv)
}
addr = (struct sockaddr_inarp *)(rtm + 1);
sdl = (struct sockaddr_dl *)(SA_SIZE(addr) + (char *)addr);
-   if (addr-sin_addr.s_addr == dst-sin_addr.s_addr) {
-   printf(set: proxy entry exists for non 802 device\n);
-   return (1);
-   }
 
if ((sdl-sdl_family != AF_LINK) ||
(rtm-rtm_flags  RTF_GATEWAY) ||
___
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to svn-src-head-unsubscr...@freebsd.org