From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 02:43:58 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 E3E5F16A400 for ; Thu, 19 Apr 2007 02:43:58 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from thing1.auspcmarket.com.au (mail.fromorbit.com [203.31.169.65]) by mx1.freebsd.org (Postfix) with ESMTP id AC06C13C4AE for ; Thu, 19 Apr 2007 02:43:58 +0000 (UTC) (envelope-from alan@fromorbit.com) Received: from [192.168.1.99] (unknown [192.168.1.99]) by thing1.auspcmarket.com.au (Postfix) with ESMTP id 0090C5D25 for ; Thu, 19 Apr 2007 12:43:57 +1000 (EST) From: Alan Garfield To: freebsd-net@freebsd.org Content-Type: text/plain Date: Thu, 19 Apr 2007 12:43:57 +1000 Message-Id: <1176950637.4175.59.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit 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: Thu, 19 Apr 2007 02:43:59 -0000 On Wed, 2007-04-18 at 19:56 +0100, Bruce M. Simpson wrote: > 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. Might have to this book to my collection. The information available on the net isn't all that conclusive (when is it ever :). > In BSD, ARP lives in the > routing table, which can be confusing to newcomers; such entries have > the RTF_LLINFO flag set. You're telling me about confusing to newcomers! :) > 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. This sounds like the right way. I think static ARP and IFF_SMART would fix my little issue. Are there any examples of using IFF_SMART in the kernel code base? Thanks, Alan.