bin/105334: Error in output of tcpdump

[Ricardo Nabinger Sanchez]

The following reply was made to PR bin/105334; it has been noted by GNATS.

From: Ricardo Nabinger Sanchez <rnsanchez at wait4.org>
To: Oliver Fromme <olli at lurza.secnetix.de>
Cc: FreeBSD-gnats-submit at FreeBSD.org
Subject: Re: bin/105334: Error in output of tcpdump
Date: Thu, 9 Nov 2006 16:07:55 -0200

 On Thu, 9 Nov 2006 18:35:44 +0100 (CET)
 Oliver Fromme <olli at lurza.secnetix.de> wrote:
 
 > Ricardo Nabinger Sanchez wrote:
 >  > Oliver Fromme wrote:
 >  > 
 >  > > 	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
 >  > 
 >  > Not sure if it makes sense, but 2714894848 & 65535 == 1024.  Any
 >  > chances that this port was indeed used during your capture (perhaps
 >  > cross-checking with netstat)?
 > 
 > No, the actual port was 982, which seems to be completely
 > unrelated to the numbers printed by tcpdump.  I converted
 > the "suspicios" numbers to hex:
 > 
 > 2714894848 == 0xa1d20200
 > 3251765760 == 0xc1d20200
 > 652476928  == 0x26e40200
 > 1054278144 == 0x3ed70200
 > 98828800   == 0x05e40200
 > 
 > The only common patter is 0x0200 (decimal 1024) in the
 > lower 16 bits.
 > 
 > Could this be a subtle compiler bug?  I've compiled the
 > system without any special compiler settings.  make.conf
 > is empty.
 
 It's possible, but I think this is the least expected cause.
 
 > 
 >  > In contrib/tcpdump/addrtoname.c:621:638 (-CURRENT):
 >  > [...]
 > 
 > The source you quoted looks OK to me.  I can't see anything
 > that could explain the symptom.
 
 The printed number was a 16 bit integer cast to a 32 bit one, and it got
 mangled somehow.
 
 > 
 >  > Are you running i386 binary on an AMD64/EMT64 (or another
 >  > 64 bits variant)?
 > 
 > It's all i386 32bit (both kernel + userland).  I don't even
 > know if the machine supports 64bit, it's a Xeon 3.2 GHz.
 > The dmesg says "AMD Features=0x20000000<LM>", does that
 > mean "long mode", i.e. 64bit?  Anyway, I'm running 32bit,
 > and going to 64bit is not an option.
 
 I'd recommend you to capture a tcpdump trace, if possible, with -w option.
 Something like:
 
 	# tcpdump -c 100 -s 1600 -w oddport.dump
 
 To save 100 packets and probably some that triggers this issue.  With this
 (small) dump we can debug tcpdump and see what's going wrong.
 
 Regards. :)
 
 ps: my previous message was classified as spam (and discarded), but I'm
 subscribed to the list.  Odd, too.
 
 -- 
 Ricardo Nabinger Sanchez     <rnsanchez@{gmail.com,wait4.org}>
 Powered by FreeBSD
 
   "Left to themselves, things tend to go from bad to worse."