From owner-freebsd-current@FreeBSD.ORG Tue Dec 23 13:36:55 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6371065675; Tue, 23 Dec 2008 13:36:55 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.freebsd.org (Postfix) with ESMTP id 110558FC23; Tue, 23 Dec 2008 13:36:54 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from [192.168.2.100] ([172.21.151.1]) by smtp-1.dlr.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Dec 2008 14:36:52 +0100 Message-ID: <4950E95C.9060307@dlr.de> Date: Tue, 23 Dec 2008 14:36:28 +0100 From: Hartmut Brandt User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: "Li, Qing" References: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> In-Reply-To: <55f001c9639d$875f14ec$7202020a@internal.cacheflow.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Dec 2008 13:36:52.0863 (UTC) FILETIME=[83E0E0F0:01C96503] Cc: Gerald Pfeifer , Vladimir Grebenschikov , Kip Macy , Qing Li , freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: Re: HEADSUP: arp-v2 has been committed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2008 13:36:55 -0000 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