Date: Mon, 10 Jun 1996 20:35:30 -0700 From: Ted Lemon <mellon@fugue.com> To: Terry Lambert <terry@lambert.org> Cc: thorpej@nas.nasa.gov, davidg@root.com, freebsd-hackers@freebsd.org Subject: Re: Swapped ethertype in BPF output? Message-ID: <199606110335.UAA28829@toccata.fugue.com> In-Reply-To: Your message of "Mon, 10 Jun 1996 19:46:13 PDT." <199606110246.TAA00972@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Depends. Are you imposing meaning on the bytes by swapping them, > and is that meaning potentially incorrect (ie: can I get packets > where the meaning isn't the same, and therefore swapping is incorrect?). In order for the byte order on the packet to be wrong, the kernel has to do something extra to it. The behaviour of all the other BPF systems I've tried is to leave the packet alone and assume that the user program knows what it's doing. I believe that this makes the most sense. > I think that the commited change to move the assumption above the BPF > layer was done to support one of the AppleTalk servers (can't remember > which one, off the top of my head) because you could not assume that > the packet was Etherne_II vs. 802.2 vs. 802.3. This may explain why I've never been able to get CAP working on NetBSD/i386 or NetBSD/pmax (both little-endian), but it works just fine on SunOS (big-endian). Based on what you've said and based on my experiences trying to figure out the CAP sources, I'd guess that the bug is in CAP, not in BPF as it was *before* that change was made to it. _MelloN_
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606110335.UAA28829>