Date: Sat, 08 Jun 1996 18:18:46 GMT From: jmf@free-gate.com (Jean-Marc Frailong) To: Dan Busarow <dan@dpcsys.com> Cc: hackers@FreeBSD.ORG Subject: Re: ISC dhcp, AF_UNSPEC & bpf bugs Message-ID: <31b9afb4.953215476@192.168.1.1> In-Reply-To: <Pine.SV4.3.91.960607234729.8732B-100000@cedb> References: <Pine.SV4.3.91.960607234729.8732B-100000@cedb>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Jun 1996 00:04:02 -0700 (PDT), you wrote: >On Fri, 7 Jun 1996, David Greenman wrote: >Since user applications should _always_ use htons or nstoh (I don't believe >anyone has ever disputed that), the libary and system calls should _always_ >return network order. > >So system/system or system/library calls should _always_ expect to receive >their natural byte order (network) and not use a user (application) level >function (nstoh). Yes, the problem is not really what is done inside the kernel (this is a taste issue), but what is visible to applications. In this respect, the current BPF behaviour is broken since all network apps expect strict network byte order. This can be fixed in bpf.c only, by adding a byte swap for the Ethernet case in bpf_movein. This fix breaks a minimal number of applications. AFAIK, in 2.1R, the only users of bpf writes are rarpd and rbootd, with one-liner fixes. Changing the kernel semantics for AF_UNSPEC is more tricky, and I am not confident of having stepped through all the implications. Also, there may be more changes for -current due to IPX & ATALK support. What is the right way to proceed on this ? I am new to the FreeBSD scene, and would appreciate some info on the 'proper procedure' :-) In parallel, I'll send a message to the ISC DHCP list mentionning the application-level workaround for FreeBSD. Jean-Marc Frailong jmf@free-gate.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?31b9afb4.953215476>