Date: Thu, 15 Aug 1996 18:19:28 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: joerg_wunsch@uriah.heep.sax.de Cc: freebsd-bugs@freebsd.org, clary@elec.uq.edu.au Subject: Re: rarpd stops working on FreeBSD 2.1.5-RELEASE Message-ID: <199608152219.SAA12997@skynet.ctr.columbia.edu> In-Reply-To: <199608151951.VAA01950@uriah.heep.sax.de> from "J Wunsch" at Aug 15, 96 09:51:14 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Of all the gin joints in all the towns in all the world, J Wunsch had to walk into mine and say: > As Clary Harridge wrote: > > > When rarpd is configured and running it responds OK to rarp requests, > > however after some hours is stops responding. > > Any syslog messages? Is it still running? Does it dump core? > > I suspect it's being rarely used this days, so pending bugs are less > likely to be found than for many other software. Don't say things like that. All parts of the OS are important. Bugs should be fixed no matter where they arise. Next you'll want to have rarod removed from the source tree. I hate to break it to you, but there are still quite a few X terminals and Sun workstations out there that use RARP for booting. > Anyway, the source > code not been changed since FreeBSD 2.0.5. I think it should have been, at least once. I remember there was one thing that drove me mad when I tried to get it to work: when specifying the ethernet frame type, I had to explicitly _not_ use htons() even though I did have to use htons() for other fields (the arp_op value for example had to be specified as htons(ARPOP_REVREPLY) but the ether_type value had to be specified as ETHERTYPE_REVARP, without the byte swapping). By contrast, for NetBSD, you need to use htons() for everything. I seem to recall reading somewhere that this was due to a bug in BPF (possibly it swapped the bytes itself which turned the htons() in the application into a no-op) but I don't know what was ever done about it. I was hoping that whoever investigated the problem would also deal with rarpd, since rarpd would stop working once the bug was fixed. There's a nice big comment in rarpd.c that talks about this too. Anyway, I'm wondering if maybe this could be caused by the fact that rarpd never closes its BPF descriptors. Perhaps you need to flush them after a while. There are, unfortunately, a lot of variables involved: it could be rarpd, it could be BPF, it could be the particular ethernet driver you're using, it could even be the arp table updating code (which I actually plagiarized from arp(8).) It would be nice if you could find a way to consistently reproduce the problem and determine whether or not it's dependent on any particular ethernet driver. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "If you're ever in trouble, go to the CTR. Ask for Bill. He will help you." =============================================================================
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608152219.SAA12997>