Re: HEADSUP: arp-v2 has been committed

Li, Qing wrote:
> Yes, at least in the IPv4 case, I still generate the routing messages whenever entries are modified, so you can still wait for notifications on the routing socket. One should check for the address family AF_LINK type instead of checking for RTF_LLINFO flag. It's an over sight this note was not attached to the commit message.
>
> There are two locations in ND6 where I temporarily disabled rtmsg generation pending further investigation. I have a note-to-self for that in the code comment.
>
> Since only ARP entries are returned, you are in fact getting some performance gain. The userland application should also be simplified a little because the list walking code does not have to check for non-ARP entries.
>   

Its not that easy, but fixable :-)  Up to now I could use common code to 
handle routing message from the routing socket and the sysctl. This is 
not possible anymore, because most of the fields in the sysctl's routing 
message are just zero. The following should fix this (at least to the 
extend bsnmp needs it):

Index: in.c
===================================================================
--- in.c    (revision 186335)
+++ in.c    (working copy)
_at__at_ -1200,6 +1200,10 _at__at_
              */
             bzero(&arpc, sizeof(arpc));
             arpc.rtm.rtm_msglen = sizeof(arpc);
+            arpc.rtm.rtm_version = RTM_VERSION;
+            arpc.rtm.rtm_type = RTM_GET;
+            arpc.rtm.rtm_flags = RTF_UP;
+            arpc.rtm.rtm_addrs = RTA_DST | RTA_GATEWAY;
             arpc.sin.sin_family = AF_INET;
             arpc.sin.sin_len = sizeof(arpc.sin);
             arpc.sin.sin_addr.s_addr = SIN(lle)->sin_addr.s_addr;

Also one thing that would be extremly helpful is a short description of 
that interface arp(4). Currently one has to reverse engineer arp.c to 
understand how to do things.

A last thing: I wonder if this would have been a good chance to get rid 
of that ugly sockaddr_inaddr construct. It looks like it is used only to 
hold the proxy flag, right? Couldn't we just use sockaddr_in and put 
that flag elsewhere. Having a single sa_family value, but two different 
struct sockaddr depending on the context defeats any kind of generic 
sockaddr handling.

harti