fake MAC addresses and ARP

[Alan Garfield]

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.