bin/105334: Error in output of tcpdump
Oliver Fromme
olli at secnetix.de
Thu Nov 9 12:30:34 UTC 2006
>Number: 105334
>Category: bin
>Synopsis: Error in output of tcpdump
>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 09 12:30:31 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator: Oliver Fromme
>Release: FreeBSD 6.2-PRERELEASE i386
>Organization:
secnetix GmbH & Co. KG
http://www.secnetix.de/bsd
>Environment:
System: FreeBSD hostname 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #0: Wed Nov 8 19:08:42 CET 2006 root at hostname:/localdisk/usr/obj/localdisk/usr/src/sys/MYSMP i386
RELENG_6 sources synced November 8th.
>Description:
While trying to debug a problem with NFS mounts via TCP,
I used the following tcpdump(1) command to watch traffic
on lo0. Note that some (but not all) of the port numbers
are wrong:
127.0.0.1.2714894848 > 127.0.0.1.2049
127.0.0.1.2049 > 127.0.0.1.3251765760
127.0.0.1.982 > 127.0.0.1.2049
127.0.0.1.982 > 127.0.0.1.2049
127.0.0.1.2049 > 127.0.0.1.982
127.0.0.1.1054278144 > 127.0.0.1.2049
127.0.0.1.2049 > 127.0.0.1.981
127.0.0.1.981 > 127.0.0.1.2049
127.0.0.1.98828800 > 127.0.0.1.2049
127.0.0.1.2049 > 127.0.0.1.652476928
127.0.0.1.981 > 127.0.0.1.2049
127.0.0.1.981 > 127.0.0.1.2049
127.0.0.1.2049 > 127.0.0.1.981
Port numbers are 16 bit, so 65535 is the maximum value.
Obviuously there is a problem with displaying those
numbers in tcpdump.
In case it matters: IPF is present, but disabled, and
IPFW only contains the default rule that allows anything.
The machine is dual-CPU with hyperthreading, i.e. four
processors are detected during boot, but only two of them
are used because machdep.hyperthreading_allowed=0.
The problem does not depend on lo0 or TCP: I've seen the
same problem when tcpdumping UDP NFS traffic on a vlan
interface (parent was a bge(4) NIC). But only NFS seems
to be affected: I don't see the problem with SSH traffic.
The tcpdump options don't matter: I see the problem with
a plain "tcpdump -i <interface>", too.
# tcpdump -i lo0 -n -l -s 1600 -v -v -v
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 1600 bytes
12:42:04.184960 IP (tos 0x0, ttl 64, id 15273, offset 0, flags [DF], proto: TCP (6), length: 64) 127.0.0.1.2714894848 > 127.0.0.1.2049: 0 proc-1157627968
12:42:04.184993 IP (tos 0x0, ttl 64, id 15274, offset 0, flags [DF], proto: TCP (6), length: 64) 127.0.0.1.2049 > 127.0.0.1.3251765760: reply ERR 0
12:42:04.185025 IP (tos 0x0, ttl 64, id 15275, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.982 > 127.0.0.1.2049: ., cksum 0xaefb (correct), 2592483171:2592483171(0) ack 2258073171 win 35840 <nop,nop,timestamp 5880112 5880112>
12:42:04.185075 IP (tos 0x0, ttl 64, id 15276, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.982 > 127.0.0.1.2049: F, cksum 0xaefa (correct), 0:0(0) ack 1 win 35840 <nop,nop,timestamp 5880112 5880112>
12:42:04.185099 IP (tos 0x0, ttl 64, id 15277, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.2049 > 127.0.0.1.982: ., cksum 0xaefa (correct), 1:1(0) ack 1 win 35840 <nop,nop,timestamp 5880112 5880112>
12:42:05.186138 IP (tos 0x0, ttl 64, id 15456, offset 0, flags [DF], proto: TCP (6), length: 64) 127.0.0.1.1054278144 > 127.0.0.1.2049: 0 proc-1157627956
12:42:05.186174 IP (tos 0x0, ttl 64, id 15457, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.2049 > 127.0.0.1.981: ., cksum 0x0a93 (correct), 3949479685:3949479685(0) ack 1347601746 win 35840 <nop,nop,timestamp 5881112 5034112>
12:42:05.186187 IP (tos 0x0, ttl 64, id 15458, offset 0, flags [DF], proto: TCP (6), length: 40) 127.0.0.1.981 > 127.0.0.1.2049: R, cksum 0x9063 (correct), 1347601746:1347601746(0) win 0
12:42:08.189411 IP (tos 0x0, ttl 64, id 15990, offset 0, flags [DF], proto: TCP (6), length: 64) 127.0.0.1.98828800 > 127.0.0.1.2049: 0 proc-1157627968
12:42:08.189445 IP (tos 0x0, ttl 64, id 15991, offset 0, flags [DF], proto: TCP (6), length: 64) 127.0.0.1.2049 > 127.0.0.1.652476928: reply ERR 0
12:42:08.189478 IP (tos 0x0, ttl 64, id 15992, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.981 > 127.0.0.1.2049: ., cksum 0x44f1 (correct), 888257620:888257620(0) ack 3935299000 win 35840 <nop,nop,timestamp 5884112 5884112>
12:42:08.189532 IP (tos 0x0, ttl 64, id 15993, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.981 > 127.0.0.1.2049: F, cksum 0x44f0 (correct), 888257620:888257620(0) ack 3935299000 win 35840 <nop,nop,timestamp 5884112 5884112>
12:42:08.189556 IP (tos 0x0, ttl 64, id 15994, offset 0, flags [DF], proto: TCP (6), length: 52) 127.0.0.1.2049 > 127.0.0.1.981: ., cksum 0x44f0 (correct), 3935299000:3935299000(0) ack 888257621 win 35840 <nop,nop,timestamp 5884112 5884112>
>How-To-Repeat:
Use the above tcpdump with some NFS traffic, and watch
the port numbers.
>Fix:
unknown
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the freebsd-bugs
mailing list