Bug 22545

Summary:	tcpdump's filters fail on tun0 (userland PPP)
Product:	Base System	Reporter:	Peter Pentchev <roam>
Component:	bin	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	Unspecified
Hardware:	Any
OS:	Any

Description Peter Pentchev 2000-11-02 16:20:01 UTC

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 :)

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..
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? :)

Comment 1 des 2000-11-02 16:34:24 UTC

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

Comment 2 Peter Pentchev 2000-11-02 16:38:31 UTC

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.

Comment 3 Dag-Erling Smørgrav freebsd_committer

2000-11-02 17:01:39 UTC

State Changed
From-To: open->closed

Already fixed.