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>