From owner-freebsd-bugs Thu Aug 15 15:20:06 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA29466 for bugs-outgoing; Thu, 15 Aug 1996 15:20:06 -0700 (PDT) Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA29396 for ; Thu, 15 Aug 1996 15:19:57 -0700 (PDT) Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.12/8.6.9) id SAA12997; Thu, 15 Aug 1996 18:19:30 -0400 From: Bill Paul Message-Id: <199608152219.SAA12997@skynet.ctr.columbia.edu> Subject: Re: rarpd stops working on FreeBSD 2.1.5-RELEASE To: joerg_wunsch@uriah.heep.sax.de Date: Thu, 15 Aug 1996 18:19:28 -0400 (EDT) Cc: freebsd-bugs@freebsd.org, clary@elec.uq.edu.au In-Reply-To: <199608151951.VAA01950@uriah.heep.sax.de> from "J Wunsch" at Aug 15, 96 09:51:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-bugs@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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." =============================================================================