It appears that Red Hat Linux 6.1 picked up some patches to "libpcap" from Alexey Kuznetsov, which change the format of the per-packet header in capture files. Unfortunately, it also appears that you may have picked up an older version of that patch, which doesn't change the magic number of the capture file; this means that "tcpdump", and other programs that use "libpcap", will write out capture files that are unreadable by programs not using the modified "libpcap", such as "tcpdump" on any system that doesn't have that patch, or Ethereal. At least one user of Ethereal has sent mail to the "ethereal-users" mailing list indicating that Ethereal cannot read a capture file written with "tcpdump" on a Red Hat 6.1 system. Please either pick up a later version of Alexey's patch, or, at least, change the magic number, in capture files that have the "ifindex", "protocol", and "pkt_type" fields in the "struct pcap_pkthdr" structure, to 0xa1b2cd34, that being the magic number that Alexey uses for his modified capture file format in later patches. Please also provide this as an update, so that, if an Ethereal user has this problem, we can tell them to get an update from the Red Hat Web site. (I will be adding support for Alexey's modified capture file format to Ethereal soon.)
Tcpdump and libpcap are now being actively maintained at http://www.tcpdump.org Redhat may want to incorporate versions from this effort in their distribution.
*** Bug 6718 has been marked as a duplicate of this bug. ***
*** Bug 7921 has been marked as a duplicate of this bug. ***
Fixed (by upgrading to latest ANK snapshot) in tcpdump-3.4-17. Meanwhile, the tcpdump.org offering seems not quite ready for prime time, although I'll probably upgrade to that version if/when they have a stable release.
*** Bug 9243 has been marked as a duplicate of this bug. ***
Sorry about entering the dupe. I did a quick search, but missed it. Will a patched RPM be coming out soon? The comments from December 22nd indicated this was being fixed. This problem is causing some significant issues in the field. Thanks.
Note that a later version of the Kuznetzov code won't necessarily fix the problem with Etherpeek; the later version of the code merely causes the non-standard capture file format to have a different magic number, so that code that is aware of the non-standard format can distinguish between files in the standard format and files in the new format simply by looking at the magic number (rather than, say, going through the contortions that Ethereal's capture-file-reading library does). If Etherpeek doesn't know about the Kuznetzov changes, it won't be able to read capture files from future versions of 6.1. (However, the capture-file-reading library in the latest version of Ethereal can also write capture files in either standard, Red Hat 6.1, or Kuznetzov-with-different-magic-number format, and the latest version of Ethereal also comes with a "editcap" program that can be used to translate capture files from one format to another, so it should be possible to turn RH 6.1 or Kuznetzov-with-a-different-magic-number capture files into standard libpcap files - if that doesn't work, it's a bug, and should be reported to "ethereal-dev".) Note also that the current tcpdump.org version of libpcap can neither read nor write Red Hat 6.1 or Kuznetzov-with-a-different-magic-number capture files.
("Future versions of 6.1" in my previous comment should read "future versions of Red Hat", assuming Red Hat Linux continues to use the Kuznetzov code, and to write files in the modified format.)
*** Bug 19690 has been marked as a duplicate of this bug. ***