Date: Thu, 19 Apr 2007 12:01:09 +1000 From: Alan Garfield <alan@fromorbit.com> To: "Bruce M. Simpson" <bms@incunabulum.net> Cc: freebsd-net@freebsd.org Subject: Re: fake MAC addresses and ARP Message-ID: <1176948069.4175.44.camel@hiro.auspc.com.au> In-Reply-To: <46266861.8040907@incunabulum.net> References: <1176781003.6367.12.camel@hiro.auspc.com.au> <46266861.8040907@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1176948069.4175.44.camel>