From roam@orbitel.bg  Thu Nov  2 08:12:47 2000
Return-Path: <roam@orbitel.bg>
Received: from ringworld.oblivion.bg (beleriand.online.bg [195.138.137.181])
	by hub.freebsd.org (Postfix) with SMTP id 2839137B4D7
	for <FreeBSD-gnats-submit@freebsd.org>; 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 <roam@orbitel.bg>
Reply-To: Peter Pentchev <roam@orbitel.bg>
To: FreeBSD-gnats-submit@freebsd.org
Subject: problems with tcpdump and tun0 (userland PPP)
X-Send-Pr-Version: 3.2

>Number:         22545
>Category:       bin
>Synopsis:       tcpdump's filters fail on tun0 (userland PPP)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 02 08:20:01 PST 2000
>Closed-Date:    Thu Nov 2 09:01:39 PST 2000
>Last-Modified:  Thu Nov 02 09:01:53 PST 2000
>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:

From: Dag-Erling Smorgrav <des@ofug.org>
To: Peter Pentchev <roam@orbitel.bg>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22545: problems with tcpdump and tun0 (userland PPP)
Date: 02 Nov 2000 17:34:24 +0100

 Peter Pentchev <roam@orbitel.bg> writes:
 > RELENG_4 built from October 31, 2000 sources.
 
 Some bpf-related bugs in if_tun were fixed earlier today. Try to
 update your sources, verify that you have /sys/net/if_tun.c rev.
 1.74.2.2, re-build, and let us know if it fixes your problem.
 
 DES
 -- 
 Dag-Erling Smorgrav - des@ofug.org
 

From: Peter Pentchev <roam@orbitel.bg>
To: Dag-Erling Smorgrav <des@ofug.org>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/22545: problems with tcpdump and tun0 (userland PPP)
Date: Thu, 2 Nov 2000 18:38:31 +0200

 On Thu, Nov 02, 2000 at 05:34:24PM +0100, Dag-Erling Smorgrav wrote:
 > Peter Pentchev <roam@orbitel.bg> writes:
 > > RELENG_4 built from October 31, 2000 sources.
 > 
 > Some bpf-related bugs in if_tun were fixed earlier today. Try to
 > update your sources, verify that you have /sys/net/if_tun.c rev.
 > 1.74.2.2, re-build, and let us know if it fixes your problem.
 
 Oops.. yeah, I saw the commit message, didn't quite realize that
 tcpdump was using bpf :(  Stupid.. off to cvsup.. and to get
 some more Coke..
 
 Thanks for the flash reply :)
 
 G'luck,
 Peter
 
 -- 
 This sentence claims to be an Epimenides paradox, but it is lying.
 
State-Changed-From-To: open->closed 
State-Changed-By: des 
State-Changed-When: Thu Nov 2 09:01:39 PST 2000 
State-Changed-Why:  
Already fixed. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=22545 
>Unformatted:
