Red Hat Bugzilla – Bug 213968
tcpdump prints erroneously large port numbers
Last modified: 2007-11-30 17:11:47 EST
Description of problem:
# tcpdump -vvvvvv -n -s 1500
16:38:57.336507 arp reply 18.104.22.168 is-at 00:0e:a6:8d:2c:a7
16:39:14.935220 IP (tos 0x0, ttl 64, id 30439, offset 0, flags [+], proto: UDP
(17), length: 1500) 22.214.171.124.3796435621 > 126.96.36.199.2049: 1472 write fh
150,140/3805627648 4096 (4096) bytes @ 0 <filesync>
Notice the source port it prints is 3796435621. Thats pretty amazing
concidering the port numbers top out at 64k. I suspect some format string
problem is being uncovered by the amd64 64-bit code.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. tcpdump -vvvvvv -n -s 1500
2. look for port number > 64k
Ports over 64k printed
Ports with numbers 1-64k
Can you send me a file created with tcpdump -w, which shows the large port number?
(In reply to comment #1)
> Can you send me a file created with tcpdump -w, which shows the large port number?
I've only seen the large port numbers occur with nfs over udp packets.
Unfortunately, tcpdumps of nfs traffic is the one thing I feel very
Looking at the code in /usr/src/redhat/BUILD/tcpdump-3.9.4/tcpdump-3.9.4/print-nfs.c
nfsreply_print and nfsreq_print, it appears that the large numbers that are
printed in the port-number position are not the port numbers at all but the XID
(some 32-bit nfs transaction ID number). Just to make it more confusing, the
"port" number printed for the server's side of the address.port is indeed the
nfs port. It is only the client's side that gets the XID printed where tcpdump
normally prints the port number.
This is a highly confusing interface design, and will probably continue to be
flagged as a bug until it is changed. It isn't a coding error though.
Ok, thanks for the analysis.
But I have to close it as NOTABUG since it's documented in the man page. Output
of tcpdump is protocol dependent and for NFS requests and replies the
transaction id is printed.