From nobody  Sat Dec 14 03:07:43 1996
Received: (from nobody@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id DAA21942;
          Sat, 14 Dec 1996 03:07:43 -0800 (PST)
Message-Id: <199612141107.DAA21942@freefall.freebsd.org>
Date: Sat, 14 Dec 1996 03:07:43 -0800 (PST)
From: graphix@iastate.edu
To: freebsd-gnats-submit@freebsd.org
Subject: libpcap after 0.2.0 does not work properly with tun devices
X-Send-Pr-Version: www-1.0

>Number:         2212
>Category:       bin
>Synopsis:       libpcap after 0.2.0 does not work properly with tun devices
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Dec 14 03:10:01 PST 1996
>Closed-Date:    Wed Dec 18 09:08:26 PST 1996
>Last-Modified:  Wed Dec 18 09:08:54 PST 1996
>Originator:     Kent Vander Velden
>Release:        FreeBSD 3.0-CURRENT
>Organization:
Iowa State University
>Environment:
FreeBSD pseudo.cc.iastate.edu 3.0-CURRENT FreeBSD 3.0-CURRENT #0: Mon Dec  9 04:50:20 CST 1996     kent@pseudo.cc.iastate.edu:/usr/src/sys/compile/PSEUDO  i386

>Description:
If a capture string is given to libpcap, either no packets will be 
captured or the wrong ones will be.  The problem started with 0.2.1
and is also in 0.3.0 which was recently released.
>How-To-Repeat:
tcpdump -i tun0 port telnet
telnet host

nothing appears from tcpdump
>Fix:

>Release-Note:
>Audit-Trail:

From: Bill Fenner <fenner@parc.xerox.com>
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
State-Changed-From-To: open->closed 
State-Changed-By: fenner 
State-Changed-When: Wed Dec 18 09:08:26 PST 1996 
State-Changed-Why:  
Fixed in contrib/libpcap/gencode.c rev 1.3 
>Unformatted:
