From owner-freebsd-net@FreeBSD.ORG Thu Apr 19 02:01:10 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 BB61E16A400 for ; Thu, 19 Apr 2007 02:01:10 +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 8120B13C455 for ; Thu, 19 Apr 2007 02:01:10 +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 D1A265C19; Thu, 19 Apr 2007 12:01:09 +1000 (EST) From: Alan Garfield To: "Bruce M. Simpson" In-Reply-To: <46266861.8040907@incunabulum.net> References: <1176781003.6367.12.camel@hiro.auspc.com.au> <46266861.8040907@incunabulum.net> Content-Type: text/plain Date: Thu, 19 Apr 2007 12:01:09 +1000 Message-Id: <1176948069.4175.44.camel@hiro.auspc.com.au> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP 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:01:10 -0000 On Wed, 2007-04-18 at 19:50 +0100, Bruce M. Simpson wrote: > Some ideas: > > 1. Enable IFF_STATICARP on your interface to stop ARP sending out to > resolve the IP/MAC address tuple. I'll try this. > 2. Consider that you can deal with resolution in userland (RTF_RESOLVE) > but this involves changing the net's entry (route) in the FTE. You'd > then process RTM_RESOLVE messages and install routes yourself -- it's > possible to do arp in userland with this. Ok that's a little above my head, but I'll look into it. :) The IP addresses and such are setup by a userland task already. So having to adjust ARP wouldn't be out of the question. > 3. Try to avoid using the 169.254.0.0/16 prefix as it has a specific > meaning. We don't implement interface scoping for these addresses yet so > the FTE can't deal with them appearing more than once for the same > subnet; it may be easier to pick something else -- note that if ARP is > enabled for an interface with one of these addresses, all ARP traffic is > forced to be broadcast as per the zeroconf RFCs. Unfortunately that's the IP addresses the little SP on the motherboard is coded to use. It can be changed after the userland task starts and configures both interfaces by the back-channel traffic over the interface, but I can't really get away from this subnet, the manufacturer has picked it. :( Seemed a little silly to me too. Thanks, -A.