Date: Thu, 9 Nov 2006 18:10:25 GMT From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/105334: Error in output of tcpdump Message-ID: <200611091810.kA9IAPUP071577@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/105334; it has been noted by GNATS.
From: Ricardo Nabinger Sanchez <rnsanchez@wait4.org>
To: Oliver Fromme <olli@lurza.secnetix.de>
Cc: FreeBSD-gnats-submit@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@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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611091810.kA9IAPUP071577>