Re: fake MAC addresses and ARP

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.

_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages