Bug 66942 - tcpdump capture can't be played back with tcpdump
tcpdump capture can't be played back with tcpdump
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: tcpdump (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-18 17:06 EDT by Chris Ricker
Modified: 2008-05-01 11:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-03-10 10:35:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tcpdump packet capture (2.56 KB, application/octet-stream)
2002-06-18 17:07 EDT, Chris Ricker
no flags Details

  None (edit)
Description Chris Ricker 2002-06-18 17:06:46 EDT
I made a tcpdump capture using the command

# tcpdump -n -i eth0 -w dhcp-request2 "udp port (67 or 68)"

(debugging a DHCP problem I'm having)

When I try to play back the capture, I get an error:

[root@class2 root]# tcpdump -r dhcp-request2 
13:08:29.861599 0:0:ff:ff:ff:ff 0:0:0:0:0:0 ffff 590: 
			 0004 757a 8c29 0800 4500 0240 0000 0000
			 3c11 7cae 0000 0000 ffff ffff 0044 0043
			 022c aad7 0101 0600 758d af03 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0004 757a 8c29 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 6382 5363 3501 0139 0205 dc3c 0d45 7468
			 6572 626f 6f74 2d35 2e30 3704 0103 0c2b
			 ff00 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
			 0000 0000 0000 0000 0000 0000 0000 0000
tcpdump: pcap_loop: bogus savefile header
[root@class2 root]# 


ethereal plays the capture back just fine....
Comment 1 Chris Ricker 2002-06-18 17:07:29 EDT
Created attachment 61465 [details]
tcpdump packet capture
Comment 2 Harald Hoyer 2002-06-24 09:07:03 EDT
did you record the file with the same tcpdump (architecture, machine)???
Comment 3 Chris Ricker 2002-06-24 09:31:10 EDT
Yep, recorded on the same machine (1.7 ghz athlon) which won't play it back
Comment 4 Harald Hoyer 2002-06-24 09:53:56 EDT
hmm, strange... does every dumpfile fail on your machine?
Comment 5 Chris Ricker 2002-06-24 14:38:11 EDT
Nope.  I just made one (tcpdump -i eth0 -w foo) and played it back (tcpdump -r
foo) w/o problems -- it's specific to that capture.

(kaboom@gatech.edu -- login's not working for me right now)
Comment 6 Harald Hoyer 2002-06-25 04:52:22 EDT
Seems like some bytes (length of packets captured) in the dump are really wired
(off by 8). Are you sure the hardware is correct? HD and RAM are ok?
Comment 7 Chris Ricker 2002-06-25 10:35:19 EDT
AFAIK, yes.  That machine's been running since December 2001 as a small
department (ftp / web / nat / kickstart / etc.) server w/o any problems other
than this one.  I ran memtest86 over the weekend when I put it together, and it
passed then....
Comment 8 Guy Harris 2002-06-26 01:14:37 EDT
Is this just Red Hat bug 6773 returned from the dead?

That bug was apparently fixed in Red Hat 6.2, but perhaps libpcap was re-broken
in 7.3.  If not, then perhaps that version of tcpdump was either statically
linked with a broken version of libpcap, or was dynamically linked with libpcap
and is finding a broken shared-library version of libpcap on the machine in
question.

Ethereal can read the file because it has some hacks^H^H^H^H^Hheuristics I put
into it to cope with various broken versions of libpcap that write out files
with a magic number that doesn't match the per-packet header.  Libpcap doesn't
have those heuristics, as the Ethereal version of them relies on being able to
seek backwards in the capture file, and libpcap is supposed to support reading
from pipes so we'd have to put some buffering in to allow those hacks to be done
when reading from a pipe.

(Ethereal also notes that the file is a "Red Hat Linux 6.1 libpcap" file, if you
select "Summary" from the "Tools" menu.)
Comment 9 Harald Hoyer 2002-06-26 04:05:07 EDT
but why should the _same_ tcpdump suddenly produce dump files with changed headers??
Comment 10 Guy Harris 2002-06-26 05:02:42 EDT
Well, the additional fields in the per-record header are zero - including the
protocol value, so it's probably not something as simple as bug 6773.

However, the file is definitely not a valid standard tcpdump file, so the bug is
presumably somewhere in the version of libpcap or tcpdump on the system on which
it was run, or in the driver or networking stack of the kernel of the machine on
which it was run, unless it's a hardware problem.  (I.e., it's not a problem
with standard libpcap or tcpdump, unless there's some recent kernel
"improvement" that requires a change to libpcap.)

Was the bad capture made with the exact same tcpdump binary that the good
capture was made with?  Or did the user's search path somehow manage to find a
different version of tcpdump when he/she did the capture that gave the bad
tcpdump?
Comment 11 Chris Ricker 2002-06-26 10:38:23 EDT
My mistake -- I thought the system had been upgraded to 7.3, but it's actually 7.2.

tcpdump version is

tcpdump-3.6.2-10.7x

libpcap version is

libpcap-0.6.2-10.7x

Capture and playback were definitely w/ the same libs and binary;
/usr/lib/libpcap* and /usr/sbin/tcpdump are the only copies of each on the system.

So far, I've only seen this problem when I capture DHCP on that system.  The
DHCP server on it is pushing etherboot, so it does have the bizarre etherboot
menus.  Beyond that, I can't think of anything unusual about the traffic going
through the box.
Comment 12 Harald Hoyer 2003-03-10 10:35:06 EST
hmm, not much I will do... this is the only report I have on this strange bug.

Note You need to log in before you can comment on or make changes to this bug.