From owner-freebsd-bugs Thu Nov 2 8:20:15 2000 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 2272337B479 for ; Thu, 2 Nov 2000 08:20:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id IAA27391; Thu, 2 Nov 2000 08:20:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: from ringworld.oblivion.bg (beleriand.online.bg [195.138.137.181]) by hub.freebsd.org (Postfix) with SMTP id 2839137B4D7 for ; Thu, 2 Nov 2000 08:12:34 -0800 (PST) Received: (qmail 1496 invoked by uid 0); 2 Nov 2000 16:12:08 -0000 Message-Id: <20001102161208.1495.qmail@ringworld.oblivion.bg> Date: 2 Nov 2000 16:12:08 -0000 From: Peter Pentchev Reply-To: Peter Pentchev To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: bin/22545: problems with tcpdump and tun0 (userland PPP) Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 22545 >Category: bin >Synopsis: tcpdump's filters fail on tun0 (userland PPP) >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Thu Nov 02 08:20:01 PST 2000 >Closed-Date: >Last-Modified: >Originator: Peter Pentchev >Release: FreeBSD 4.2-BETA i386 >Organization: Orbitel JSCo. >Environment: RELENG_4 built from October 31, 2000 sources. [roam@ringworld ~]$ ifconfig -a rl0: flags=8843 mtu 1500 inet 192.168.13.1 netmask 0xffffff00 broadcast 192.168.13.255 inet 192.168.1.23 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:e0:18:18:f2:10 media: autoselect (100baseTX) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UT P 10baseT/UTP 100baseTX lp0: flags=8810 mtu 1500 rl0f0: flags=8842 mtu 1500 ether 00:e0:18:18:f2:10 rl0f1: flags=8842 mtu 1500 ether 00:e0:18:18:f2:10 rl0f2: flags=8842 mtu 1500 ether 00:e0:18:18:f2:10 rl0f3: flags=8842 mtu 1500 ether 00:e0:18:18:f2:10 ds0: flags=8008 mtu 65532 lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010 mtu 1500 ppp1: flags=8010 mtu 1500 ppp2: flags=8010 mtu 1500 ppp3: flags=8010 mtu 1500 sl0: flags=c010 mtu 552 tun0: flags=8151 mtu 1500 inet 195.138.137.181 --> 195.138.137.21 netmask 0xffffff00 Opened by PID 317 >Description: When filters are applied, tcpdump fails to display all traffic on a tun0 interface. tun0 is a dialup connection on which I have a ping going on at all times: [root@ringworld ~]# tcpdump -nli tun0 tcpdump: listening on tun0 17:59:49.366327 195.138.137.9 > 195.138.137.181: icmp: echo reply 17:59:50.246281 195.138.137.181 > 195.138.137.9: icmp: echo request 17:59:50.376332 195.138.137.9 > 195.138.137.181: icmp: echo reply 17:59:51.256299 195.138.137.181 > 195.138.137.9: icmp: echo request Now let's try playing around with tcpdump's filters.. [root@ringworld ~]# tcpdump -nli tun0 not icmp tcpdump: listening on tun0 18:01:38.667959 195.138.137.9 > 195.138.137.181: icmp: echo reply 18:01:39.677969 195.138.137.9 > 195.138.137.181: icmp: echo reply 18:01:40.637995 205.188.153.106.4000 > 195.138.137.181.1039: udp 34 (DF) 18:01:40.638138 195.138.137.181.1039 > 205.188.153.106.4000: udp 10 This already looks like fun - note the first two lines. The last two are from an ICQ session, as you probably can guess :) But.. what is the echo reply doing showing up in a 'not icmp' output? But the best is still to come.. Let's try to monitor a web session - simply pointing lynx at http://www.freebsd.org.. [root@ringworld ~]# tcpdump -nli tun0 tcp and port 80 tcpdump: listening on tun0 18:04:39.813185 195.138.137.181.1555 > 216.136.204.21.80: S 3046335552:304633555 2(0) win 16384 (DF) 18:04:40.380793 195.138.137.181.1555 > 216.136.204.21.80: . ack 3611557607 win 1 7520 (DF) 18:04:40.381394 195.138.137.181.1555 > 216.136.204.21.80: P 0:221(221) ack 1 win 17520 (DF) 18:04:41.630668 195.138.137.181.1555 > 216.136.204.21.80: . ack 1461 win 17520 ( DF) 18:04:41.760655 195.138.137.181.1555 > 216.136.204.21.80: . ack 2921 win 17520 ( DF) 18:04:42.560682 195.138.137.181.1555 > 216.136.204.21.80: . ack 4381 win 17520 ( DF) 18:04:42.690684 195.138.137.181.1555 > 216.136.204.21.80: . ack 5841 win 17520 ( DF) 18:04:42.870679 195.138.137.181.1555 > 216.136.204.21.80: . ack 7301 win 17520 ( DF) Alright, so there's the SYN request, the HTTP request on the third line, and then the ack's.. but.. ack's to what? The actual content is missing. Let's try a different take on this one.. [root@ringworld ~]# tcpdump -nli tun0 tcp and src port 80 tcpdump: listening on tun0 ^C 25 packets received by filter 0 packets dropped by kernel [root@ringworld ~]# I hit ^C as soon as lynx finished loading the page - still no output. I shall not paste any more logs, but this is not a TCP-specific issue - actually I stumbled on it while trying to hunt down a totally unrelated ICQ problem, and tcpdump -nli tun0 udp only showed outgoing UDP packets. (And I think the 'icmp reply' thing is.. well.. interesting :) >How-To-Repeat: I have only tested this on my personal -stable box; could anybody do any tests to see if I have mucked something up real bad? :) >Fix: Unfortunately, right now I do not have any time to research :( I'll try recompiling and debugging in a few hours, but I thought I'd report this one ASAP in view of the upcoming 4.2-R.. >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message