mogul@DECWRL.DEC.COM (Jeffrey Mogul) (09/09/87)
> 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 > BSD. 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. -Jeff Mogul (co-author of the packet filter code and of the RARP RFC)