From owner-freebsd-bugs Thu Aug 17 8:40:11 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 6F25037B72A for ; Thu, 17 Aug 2000 08:40:03 -0700 (PDT) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA70661; Thu, 17 Aug 2000 08:40:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from core.atomicbluebear.org (jenny.adsl2.pangea.ca [64.4.83.19]) by hub.freebsd.org (Postfix) with SMTP id 0283D37B7AD for ; Thu, 17 Aug 2000 08:31:53 -0700 (PDT) Received: (qmail 19699 invoked from network); 17 Aug 2000 15:31:43 -0000 Received: from meltdown.atomicbluebear.org (172.31.254.2) by core.atomicbluebear.org with QMQP; 17 Aug 2000 15:31:43 -0000 Message-Id: <20000817153139.1304.qmail@meltdown.atomicbluebear.org> Date: 17 Aug 2000 15:31:39 -0000 From: mlea@atomicbluebear.org Reply-To: mlea@atomicbluebear.org To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: kern/20686: bpf filter broken with tun interface Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 20686 >Category: kern >Synopsis: bpf filters do not behave as expected with tun interfaces >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Aug 17 08:40:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Michael Lea >Release: FreeBSD 5.0-CURRENT i386 >Organization: private user >Environment: $ uname -a FreeBSD meltdown.atomicbluebear.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Wed Aug 16 22:05:28 CDT 2000 mlea@meltdown.atomicbluebear.org:/usr/obj/usr/src/sys/PLANCK i386 $ ifconfig -a ed0: flags=8843 mtu 1400 inet 172.31.254.2 netmask 0xffffff00 broadcast 172.31.254.255 ether 00:40:05:5d:d6:d9 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 tun0: flags=8151 mtu 1400 inet 64.4.94.80 --> 64.4.82.5 netmask 0xffffffff Opened by PID 1215 >Description: When running tcpdump with filter expressions, the filter only works as expected on *outgoing* packets. For example, given a simple "positive" filter, tcpdump will only capture *outbound* packets. Given the inverse "negative" filter, tcpdump will capture both inbound & outbound packets, *including inbound packets that should have been captured in the positive filter.* >How-To-Repeat: 1. Bring up a PPP connection using user-ppp. 2. Run two (or three) tcpdump sessions to watch traffic on the PPP link: a) no filters: tcpdump -n -i tun0 b) positive filter: tcpdump -n -i tun0 icmp c) negative filter: tcpdump -n -i tun0 not icmp 3. Send controlled traffic over the PPP link (in this example, pings from a remote host and a failed TCP connection attempt). ***** REMOTE HOST ***** $ ping -c 5 64.4.94.80 PING 64.4.94.80 (64.4.94.80): 56 data bytes 64 bytes from 64.4.94.80: icmp_seq=0 ttl=255 time=97.491 ms 64 bytes from 64.4.94.80: icmp_seq=1 ttl=255 time=98.056 ms 64 bytes from 64.4.94.80: icmp_seq=2 ttl=255 time=99.096 ms 64 bytes from 64.4.94.80: icmp_seq=3 ttl=255 time=92.134 ms 64 bytes from 64.4.94.80: icmp_seq=4 ttl=255 time=96.834 ms --- 64.4.94.80 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 92.134/96.722/99.096/2.411 ms $ telnet 64.4.94.80 12345 Trying 64.4.94.80... telnet: connect to address 64.4.94.80: Connection refused telnet: Unable to connect to remote host ***** NO FILTER ***** # tcpdump -d -i tun0 (000) ret #96 # tcpdump -n -i tun0 tcpdump: listening on tun0 09:45:08.749435 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:08.749639 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:09.770319 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:09.770668 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:10.798635 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:10.798837 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:11.807835 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:11.808142 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:12.832782 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:12.833094 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:19.831059 64.4.83.19.1653 > 64.4.94.80.12345: S 1748413850:1748413850(0) win 16384 (DF) [tos 0x10] 09:45:19.831252 64.4.94.80.12345 > 64.4.83.19.1653: R 0:0(0) ack 1748413851 win 0 ^C 12 packets received by filter 0 packets dropped by kernel ***** POSITIVE FILTER ***** # tcpdump -d -i tun0 icmp (000) ld [0] (001) jeq #0x2000000 jt 2 jf 5 (002) ldb [13] (003) jeq #0x1 jt 4 jf 5 (004) ret #96 (005) ret #0 # tcpdump -n -i tun0 icmp tcpdump: listening on tun0 09:45:08.749636 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:09.770664 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:10.798833 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:11.808138 64.4.94.80 > 64.4.83.19: icmp: echo reply 09:45:12.833089 64.4.94.80 > 64.4.83.19: icmp: echo reply ^C 12 packets received by filter 0 packets dropped by kernel ***** NEGATIVE FILTER ***** # tcpdump -d -i tun0 not icmp (000) ld [0] (001) jeq #0x2000000 jt 2 jf 5 (002) ldb [13] (003) jeq #0x1 jt 4 jf 5 (004) ret #0 (005) ret #96 # tcpdump -n -i tun0 not icmp tcpdump: listening on tun0 09:45:08.749423 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:09.770306 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:10.798627 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:11.807828 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:12.832771 64.4.83.19 > 64.4.94.80: icmp: echo request 09:45:19.831049 64.4.83.19.1653 > 64.4.94.80.12345: S 1748413850:1748413850(0) win 16384 (DF) [tos 0x10] 09:45:19.831249 64.4.94.80.12345 > 64.4.83.19.1653: R 0:0(0) ack 1748413851 win 0 ^C 12 packets received by filter 0 packets dropped by kernel >Fix: The problem appears to be a byte-order problem with the address family on the incoming packet in /sys/net/if_tun.c. Examining the packets captured by tcpdump in Ethereal shows an address family of 0x00000002 on the inbound packets and a family of 0x02000000 on the outbound packets. Running tcpdump with the -e flag shows similar results. The fix is to ensure that the address family is stored in the packet in host byte order, since that is what tcpdump/libpcap is looking for. This probably means mangling the inbound packets at around if_tun.c:649 since the address family at this point will be in network byte order. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message