Bug 6773
Summary: | "tcpdump" writes out capture files others cannot read | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Guy Harris <gharris> |
Component: | tcpdump | Assignee: | Harald Hoyer <harald> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 6.1 | CC: | dts, jzinky, rodrigc |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 1999-12-22 14:47:33 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Guy Harris
1999-11-06 08:05:01 UTC
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.) |