From owner-freebsd-net@FreeBSD.ORG Wed Apr 18 18:56:56 2007 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18C5016A403 for ; Wed, 18 Apr 2007 18:56:56 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id E830F13C459 for ; Wed, 18 Apr 2007 18:56:55 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 28B76218013; Wed, 18 Apr 2007 14:57:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 18 Apr 2007 14:56:56 -0400 X-Sasl-enc: UA4ta46bCYidKw01TOMlzTgtoXKlpqlRSpw+QpE2jfhf 1176922614 Received: from [212.50.171.200] (unknown [212.50.171.200]) by mail.messagingengine.com (Postfix) with ESMTP id AA30A130FA; Wed, 18 Apr 2007 14:56:53 -0400 (EDT) Message-ID: <462669EB.7090705@incunabulum.net> Date: Wed, 18 Apr 2007 19:56:43 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Alan Garfield References: <1176861009.4426.21.camel@hiro.auspc.com.au> In-Reply-To: <1176861009.4426.21.camel@hiro.auspc.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2007 18:56:56 -0000 Alan Garfield wrote: > Hi all! > > One word.... HOW! :) > > I've no clue what this FreeBSD ARP stuff is all about, there is little > or no documentation, there are 14 different sock_addr's which seem to > have a bazillion different fields, and I cannot output a simple debug > statement without getting 'error: dereferencing pointer to incomplete > type' errors! > The ARP code is pretty well documented in TCP/IP Illustrated Volume 2 and hasn't really significantly changed. Whilst I personally dislike how reentry happens in some of the paths, it works. In BSD, ARP lives in the routing table, which can be confusing to newcomers; such entries have the RTF_LLINFO flag set. From the sounds of it, if you are having to fake MAC addresses, you would be better off just enabling static mode ARP on the interface, possibly also enabling IFF_SMART ('manages own routes') on your interface and explicitly purging and re-adding your ARP entries from within your driver rather than trying to hack the rtrequest code to munge things on the fly. arp_rtrequest() is driver-independent code and will get hooked up to your code anyway when the net/ framework notices that your driver is one of IFT_ETHER. Regards, BMS