Date: Sat, 24 Aug 1996 18:22:36 -0400 (EDT) From: Brian Tao <taob@io.org> To: Bill Paul <wpaul@skynet.ctr.columbia.edu> Cc: current@freebsd.org Subject: Re: rarpd broken on 2.2-960801-SNAP? Message-ID: <Pine.NEB.3.92.960824181350.28538Q-100000@zot.io.org> In-Reply-To: <199608242010.QAA04360@skynet.ctr.columbia.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 24 Aug 1996, Bill Paul wrote:
>
> 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.
Yeah, something must be different between the bpf in -stable and
the one in -current. htons() is necessary with -current for rarp
replies to work. The comments in FreeBSD-current and NetBSD-current
can probably be taken out now:
NetBSD-current:
#ifdef __FreeBSD__
/* BPF (incorrectly) wants this in host order. */
ep->ether_type = ETHERTYPE_REVARP;
#else
ep->ether_type = htons(ETHERTYPE_REVARP);
#endif
FreeBSD-current:
/*
* XXX Using htons(ETHERTYPE_REVARP) doesn't work: you wind
* up transmitting 0x3580 instead of the correct value of
* 0x8035. What makes no sense is that the NetBSD people
* do in fact use htons(ETHERTYPE_REVARP) in their rarpd.
* (Thank god for tcpdump or I would never have figured this
* out.)
*/
ep->ether_type = htons(ETHERTYPE_REVARP);
> 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.
I've got the source here too, but I haven't tried using it yet,
since the htons()'d rarpd works here. Now I have a similar problem
with the X terminals timing out waiting for a response from the
bootparamd server. It works the first time (so they can NFS-mount
their filesystems), but fails the second (presumably after they've
ifconfig'd their interfaces). Must be some broadcast or netmask
issue... *sigh*.
--
Brian Tao (BT300, taob@io.org, taob@ican.net)
Senior Systems and Network Administrator, Internet Canada Corp.
"Though this be madness, yet there is method in't"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.92.960824181350.28538Q-100000>