Date: 2 Nov 2000 16:12:08 -0000 From: Peter Pentchev <roam@orbitel.bg> To: FreeBSD-gnats-submit@freebsd.org Subject: bin/22545: problems with tcpdump and tun0 (userland PPP) Message-ID: <20001102161208.1495.qmail@ringworld.oblivion.bg>
next in thread | raw e-mail | index | archive | help
>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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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 <full-duplex> 100baseTX 10baseT/UT P <full-duplex> 10baseT/UTP 100baseTX <hw-loopback> lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 rl0f0: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:e0:18:18:f2:10 rl0f1: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:e0:18:18:f2:10 rl0f2: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:e0:18:18:f2:10 rl0f3: flags=8842<BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 ether 00:e0:18:18:f2:10 ds0: flags=8008<LOOPBACK,MULTICAST> mtu 65532 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet 127.0.0.1 netmask 0xff000000 ppp0: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 ppp1: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 ppp2: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 ppp3: flags=8010<POINTOPOINT,MULTICAST> mtu 1500 sl0: flags=c010<POINTOPOINT,LINK2,MULTICAST> mtu 552 tun0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> 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 <mss 1460,nop,wscale 0,nop,nop,timestamp 1471906 0> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20001102161208.1495.qmail>