Re: fake MAC addresses and ARP
- From: Alan Garfield <alan@xxxxxxxxxxxxx>
- Date: Thu, 19 Apr 2007 12:01:09 +1000
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"
- References:
- fake MAC addresses and ARP
- From: Alan Garfield
- Re: fake MAC addresses and ARP
- From: Bruce M. Simpson
- fake MAC addresses and ARP
- Prev by Date: Re: rtentry and rtrequest
- Next by Date: Re: rtentry and rtrequest
- Previous by thread: Re: fake MAC addresses and ARP
- Next by thread: Fwd: ng_tag and pf?
- Index(es):
Relevant Pages
|
