Date: Wed, 18 Apr 2007 19:56:43 +0100 From: "Bruce M. Simpson" <bms@incunabulum.net> To: Alan Garfield <alan@fromorbit.com> Cc: freebsd-net@freebsd.org Subject: Re: rtentry and rtrequest Message-ID: <462669EB.7090705@incunabulum.net> In-Reply-To: <1176861009.4426.21.camel@hiro.auspc.com.au> References: <1176861009.4426.21.camel@hiro.auspc.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Alan Garfield wrote:
> Hi all!
>
> One word.... HOW! :)
>
> I've no clue what this FreeBSD ARP stuff is all about, there is little
> or no documentation, there are 14 different sock_addr's which seem to
> have a bazillion different fields, and I cannot output a simple debug
> statement without getting 'error: dereferencing pointer to incomplete
> type' errors!
>
The ARP code is pretty well documented in TCP/IP Illustrated Volume 2
and hasn't really significantly changed. Whilst I personally dislike how
reentry happens in some of the paths, it works. In BSD, ARP lives in the
routing table, which can be confusing to newcomers; such entries have
the RTF_LLINFO flag set.
From the sounds of it, if you are having to fake MAC addresses, you
would be better off just enabling static mode ARP on the interface,
possibly also enabling IFF_SMART ('manages own routes') on your
interface and explicitly purging and re-adding your ARP entries from
within your driver rather than trying to hack the rtrequest code to
munge things on the fly. arp_rtrequest() is driver-independent code and
will get hooked up to your code anyway when the net/ framework notices
that your driver is one of IFT_ETHER.
Regards,
BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?462669EB.7090705>