> Hmmm, I modified editcap to print out the type of the file if -v flag used.
>
> I came across a problem where it lists two capture files as (null) with
> long names of modified blah blah ...
The line that prints that is
fprintf(stderr, "File %s is a %s capture file.\n", argv[optind],
wtap_file_type_string(wtap_file_type(wth)));
so it prints only two strings - the file name, and the file type string;
if it spoke of "modified ...", presumably that string wasn't null, but I
can't see the file name being a null pointer, either.
What did it list as "(null)"?
As for "modified blah blah blah", that was probably "modified libpcap",
a name chosen because I couldn't think of a better one ("Alexey
Kuznetzov's modified libpcap for Linux" just seemed too verbose).
Alexey has some patches to "libpcap" and "tcpdump" at
http://ftp.sunet.se/pub/os/Linux/ip-routing/lbl-tools/
which includes a change to "libpcap" that, on Linux, lets it capture on
all interfaces, and puts some additional information into the per-packet
header:
an index into the system's table of interfaces, of the interface
(not very useful if you're reading the capture on another
machine; in a discussion on "tcpdump-workers", I suggested
putting an encapsulation type in there, and Alexey also thinks
that'd be useful - that discussion was about a possible newer
capture file format, and I'd like it to be one that does all
that Ethereal would want);
a "protocol" field - I forget what it does, but it's not hugely
useful for Ethereal, and it's not a link-layer type;
a "packet type" field, which indicates things such as "did we
send this", "was this sent to us", "was this multicast", etc. -
I think that's in "libpcap" mainly for the benefit of programs
other than sniffers reading live packet streams.
The "Red Hat 6.1" format is just like that *except* that it's based on
an older patch of Alexey's, which *didn't* change the magic number,
causing RH 6.1 to be unable to read standard "libpcap" files and causing
Alexey's later "libpcap" readers - which read both standard and modified
format, distinguishing between them based on the magic number - to be
unable to read RH 6.1 captures; go, Red Hat! (I filed bug 6773 in their
bug system on that.)
Wiretap, when reading a "libpcap" file with the standard magic number,
tries to read the first two packets and, if that fails with the second
packet's header appearing to be corrupt, assumes it's an RH 6.1 capture
and tries reading it in that fashion. It worked on the few capture
files on which I've tried it, at least.
It also supports writing in all three formats, so people running RH 6.1
can, at least, get Ethereal to write out captures that RH 6.1's
"tcpdump" can read, as well as writing standard "libpcap" captures that
most if not all *other* "tcpdump"s cann read.
