From owner-freebsd-bugs Mon Dec 16 12:50:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01548 for bugs-outgoing; Mon, 16 Dec 1996 12:50:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id MAA01542; Mon, 16 Dec 1996 12:50:02 -0800 (PST) Date: Mon, 16 Dec 1996 12:50:02 -0800 (PST) Message-Id: <199612162050.MAA01542@freefall.freebsd.org> To: freebsd-bugs Cc: From: Bill Fenner Subject: Re: bin/2212: libpcap after 0.2.0 does not work properly with tun devices Reply-To: Bill Fenner Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR bin/2212; it has been noted by GNATS. From: Bill Fenner To: freebsd-gnats-submit@freebsd.org, graphix@iastate.edu Cc: Subject: Re: bin/2212: libpcap after 0.2.0 does not work properly with tun devices Date: Mon, 16 Dec 1996 12:46:16 PST This appears to be confusion over whether the address family is in host or network byte order. The BPF program created by an older libpcap to perform "tcpdump -i lo0 icmp" is: (000) ld [0] (001) jeq #0x2000000 jt 2 jf 5 (002) ldb [13] (003) jeq #0x1 jt 4 jf 5 (004) ret #68 (005) ret #0 and the new libpcap creates: (000) ld [0] (001) jeq #0x2 jt 2 jf 5 (002) ldb [13] (003) jeq #0x1 jt 4 jf 5 (004) ret #68 (005) ret #0 Note the difference in byte-order of the constant 2 (==AF_INET) in instruction #1. The BPF filter performs all loads in network byte order, so instruction 0 loads 0x02000000 into A, since the value is in host byte order. I will check with the LBL folks before doing anything but I think it's a straightforward fix to libpcap/gencode.c . Bill