From owner-freebsd-hackers  Mon Jun 10 16:45:00 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id QAA23785
          for hackers-outgoing; Mon, 10 Jun 1996 16:45:00 -0700 (PDT)
Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id QAA23762
          for <freebsd-hackers@freebsd.org>; Mon, 10 Jun 1996 16:44:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id QAA19007; Mon, 10 Jun 1996 16:43:35 -0700 (PDT)
Message-Id: <199606102343.QAA19007@lestat.nas.nasa.gov>
X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol
To: Ted Lemon <mellon@fugue.com>
Cc: freebsd-hackers@freebsd.org
Subject: Re: Swapped ethertype in BPF output? 
Reply-To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jason Thorpe <thorpej@nas.nasa.gov>
Date: Mon, 10 Jun 1996 16:43:35 -0700
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Mon, 10 Jun 1996 16:05:18 -0700 
 Ted Lemon <mellon@fugue.com> wrote:

 > I'm the author of the Internet Software Consortium DHCP server.  One
 > of the operating systems on which ISC dhcpd is supported is FreeBSD.
 > A FreeBSD user has reported a problem in that on FreeBSD, BPF
 > apparently swaps the ethertype supplied by the user program when
 > sending a packet.   If true, this breaks code in dhcpd that works on
 > all other platforms that support BPF, including NetBSD, BSD/OS, and
 > DEC Alpha OSF/1.
 > 
 > Is this user correct, and if so, is this a known bug that is going to
 > be fixed, or a ``feature''?   The FreeBSD port is completely clean
 > other than this, and I would really prefer not to have to put in an
 > ifdef for something like this.

Hi Ted ... long time no see :-)

It's not just the ethertype, from what I can tell...See the following 
kludge in NetBSD's rbootd(8) (the HP Remote Maintainance Protocol boot 
server):

int
SendPacket(rconn)
        register RMPCONN *rconn;
{
        /*
         *  Set Ethernet Destination address to Source (BPF and the enet
         *  driver will take care of getting our source address set).
         */
        bcopy((char *)&rconn->rmp.hp_hdr.saddr[0],
              (char *)&rconn->rmp.hp_hdr.daddr[0], RMP_ADDRLEN);
#ifdef __FreeBSD__
        /* BPF (incorrectly) wants this in host order. */
        rconn->rmp.hp_hdr.len = rconn->rmplen - sizeof(struct hp_hdr); 
#else 
        rconn->rmp.hp_hdr.len = htons(rconn->rmplen - sizeof(struct hp_hdr));
#endif
 
        /*
         *  Reverse 802.2/HP Extended Source & Destination Access Pts.
         */
        rconn->rmp.hp_llc.dxsap = htons(HPEXT_SXSAP);
        rconn->rmp.hp_llc.sxsap = htons(HPEXT_DXSAP);

[ . . . ]

It's been there ever since Mike Hibler and I helped a fellow recover a 
fairly dead HP-BSD system ... the guy ended up netbooting NetBSD/hp300, 
mounting his HP-BSD filesystems, and recovering his data (darn, those old 
HP-IB drives :-)  All the guy had was a NeXT and a PC on which he could 
install FreeBSD (happened to have a 2.0.5 CD laying around...)

I don't know if it's a bug or feature (and, am not really willing to make 
a guess either way :-), but just wanted to point out that it seems as if 
the packet length needs to be in the wrong order, too...

----save the ancient forests - http://www.bayarea.net/~thorpej/forest/----
Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939