Jeffrey Mogul (email@example.com)
8 Sep 1987 1859-PDT (Tuesday)
> From: > From: bbanerje@sjuvax.UUCP (B. Banerjee)
> c. Rarp can be added to 4.3 BSD.
> You can write a rarp daemon
> with the aid of the 'enet' ethernet packet filter software that
> was part of the ``user contributed software '' that came with 4.3
Yes, probably. I doubt that the "enet" code distributed on the 4.3 tapes
will actually work without modification (actually, the modification
required is to the interface driver code for whatever interface you are
using). As Greg Satz said in a recent message, you can probably get
the working code from someone at Stanford ... but I don't know who (it
is NOT either Greg or myself, so don't bother asking).
People at Stanford (different people, probably) also have a "rarpd" that
uses the packet filter. You could try to get that, although it really
is a fairly simple program to write.
> I personally believe that it makes the most sense to place the
> rarp handling stuff along with the 'arp' handling stuff in the
> kernel (netinet/if_ether.c).
Unfortunately, this is infeasible in a large campus, since the ARP tables
in the kernel are meant to be small and, when the overflow, it is
normally safe to throw away old entries (they will be restored if they
are used again). At a site like Stanford, where there may be hundreds
or even thousands of diskless workstations eventually, the current
kernel ARP table is clearly not going to work.
RARP is not a performance-critical protocol; a user-mode server is
the right way to go. It's sad that 4.xBSD has no mechanism to write
such servers (i.e., no link-level access mechanism); that's what the
packet filter or NIT is meant to provide. With such a mechanism, it's
trivial to put the RARP server in the right place. Maybe 4.4BSD will
do something about this.
(co-author of the packet filter code and of the RARP RFC)
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:15 GMT