Date: Sat, 24 Aug 1996 16:10:23 -0400 (EDT) From: Bill Paul <wpaul@skynet.ctr.columbia.edu> To: taob@io.org (Brian Tao) Cc: current@freebsd.org Subject: Re: rarpd broken on 2.2-960801-SNAP? Message-ID: <199608242010.QAA04360@skynet.ctr.columbia.edu> In-Reply-To: <Pine.NEB.3.92.960824021528.15003X-100000@zap.io.org> from "Brian Tao" at Aug 24, 96 02:31:38 am
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, Brian Tao had to walk into mine and say: > Has anyone run into problems using a 2.2-CURRENT server to handle > rarpd requests? I've got one here that does not seem to send out > replies, although I'm not yet entirely sure if it is the OS, or some > other variable in the equation. Are you absitively posolutely sure it's not sending out a reply, even a garbled one? When I first shoehorned rarpd into 2.0.5, I discovered that when I set the ether_type in the outgoing frame, I had to deliberately _not_ convert it to network byte order (no htons()) in order for it to go out correctly. This confused me greatly because NetBSD did (does?) use htons(). I could swear I read somewhere that this was due to a bug in BPF. It's possible someone fixed the bug, making the htons() necessary again. When using tcpdump, try to set it to watch for all packets originating at the host running rarpd, not just ARP or RARP, and make it show you the packet contents. You may in fact see a packet being sent, but it may have the frame type set wrong. Read the comments in /usr/src/usr.sbin/rarpd/rarpd.c for some more info (grep for XXX). As an experiment, try adding an htons() around ether_type and see if it makes any difference. Incidentally, you might try using a newer version of rarpd. If you grab the new bpf distribution from ftp.ee.lbl.gov (bpf.tar.Z) you'll see it has an updated rarpd in it. You should be able to compile it on FreeBSD-current (I did it the other day, but didn't get the chance to really play with it). You may not need the ethernet.c module that they supply for reading /etc/ethers since FreeBSD now has ether_aton() and friends in libc. If that works, then I'll have to import the new rarpd into the tree. [chop] > In all cases, tcpdump shows rarp requests from the terminal is > being received by the interface on the server. However, the 2.2 > server isn't sending out a reply according to tcpdump. I tried using > a 255.255.255.0 netmask on the server and renumbering the X terminal > to 10.0.0.4 (to be in the same network), to no avail. The /etc/hosts, > /etc/ethers and /tftpboot directory are all in order. > > Any ideas on what's going on? Hm. Rarpd is only supposed to be useful for machines on the same subnet. I'm not sure what effect the switch in your diagram would have. In any case, putting all the machines on the same logical subnet should have worked, so there must be something wrong with rarpd. Time for me to start testing again. -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?199608242010.QAA04360>