From owner-freebsd-bugs@FreeBSD.ORG Thu Nov 9 19:12:00 2006 Return-Path: X-Original-To: freebsd-bugs@hub.freebsd.org Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8785A16A4A7 for ; Thu, 9 Nov 2006 19:12:00 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD60B43E63 for ; Thu, 9 Nov 2006 19:10:26 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id kA9JANdE076579 for ; Thu, 9 Nov 2006 19:10:23 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id kA9JANhV076578; Thu, 9 Nov 2006 19:10:23 GMT (envelope-from gnats) Date: Thu, 9 Nov 2006 19:10:23 GMT Message-Id: <200611091910.kA9JANhV076578@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Oliver Fromme Cc: Subject: Re: bin/105334: Error in output of tcpdump X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Oliver Fromme List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2006 19:12:01 -0000 The following reply was made to PR bin/105334; it has been noted by GNATS. From: Oliver Fromme To: rnsanchez@wait4.org (Ricardo Nabinger Sanchez) Cc: FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/105334: Error in output of tcpdump Date: Thu, 9 Nov 2006 20:01:12 +0100 (CET) Ricardo Nabinger Sanchez wrote: > The printed number was a 16 bit integer cast to a 32 bit one, and it got > mangled somehow. True. > 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. Now it gets even more interesting. I did what you suggested, then tried to view the file with "tcpdump -r" (on the same machine), and it displayed "0" for the port number in all places where the big 32bit numbers where displayed previously. Then I copied the file to a different machine (running an older FreeBSD 4.x), and tcpdump there displayed all of the port numbers correctly (i.e. neither big 32bit numbers nor zero). So it is definitely purely a display problem on my RELENG_6 machine. The contents of the capture file are OK. If anyone wants to look at it anyway, here it is: http://www.secnetix.de/~olli/tmp/tcpdump.log.gz On that offending machine, the first few packets look like this (only IP:port, rest omitted): 127.0.0.1.0 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.0 127.0.0.1.911 > 127.0.0.1.2049 127.0.0.1.911 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.911 127.0.0.1.0 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.955 127.0.0.1.955 > 127.0.0.1.2049 127.0.0.1.0 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.0 On my 4.x machine, the same packets from that file are displayed correctly: 127.0.0.1.911 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.911 127.0.0.1.911 > 127.0.0.1.2049 127.0.0.1.911 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.911 127.0.0.1.955 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.955 127.0.0.1.955 > 127.0.0.1.2049 127.0.0.1.955 > 127.0.0.1.2049 127.0.0.1.2049 > 127.0.0.1.955 I've also put my binaries of tcpdump and libpcap online, in case someone wants to look for compiler errors (or just try to reproduce the problem with my binaries): http://www.secnetix.de/~olli/tmp/tcpdump http://www.secnetix.de/~olli/tmp/libpcap.so.4 They're build from RELENG_6 sources of 2006-11-08. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549