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)
@@ -1200,6 +1200,10 @@
*/
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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
