On Sun, Apr 21, 2002 at 04:47:55PM +0200, Ferm�n Gal�n M�rquez wrote:
> I'm implenting a filter to convert captured files in a (propietary) format
> used in my organization to files in libpcap format, in order to make
> post-processing
> using wide-used libpcap-based tools like Ethereal or Snort. So, I need to
> know the details of how libpcap write its files (or, equally, how the
> libpcap-based tools read them).
Hmm.
One way you could do it with libpcap would be to, with a sufficiently
recent version of libpcap (the OS on which you're running might not have
this, although the latest WinPcap should have it, and you should be able
to compile the current tcpdump.org libpcap on most if not all versions
of UNIX that support libpcap at all):
do a "pcap_open_dead()", supplying the DLT_ value for the
link-layer type the output file should have, and the snapshot
length (if your capture file cut packets short at a given
length, supply that, otherwise supply 65535, for example);
use the result of that to do a "pcap_dump_open()";
write the packets out with "pcap_dump()", and close the output
stream with "pcap_close()".
(If the format is not "proprietary" in the sense of "your organization
doesn't want to publish it", but only "proprietary" in the sense of
"your organization developed it", another possibility would be to add
support for it to Ethereal's capture-file-reading-and-writing library.
That would allow Ethereal to read them without conversion, and would
allow the "editcap" program that comes with Ethereal to convert them to
a variety of formats, including libpcap format.)
> Your information format will be very useful (thanks again! :), but
> I've found a disturbing fact about the magic number:
>
> > See: http://www.tcpdump.org/lists/workers/1999/msg00120.html
> >
> > "Date: Wed, 24 Nov 1999 22:16:49 -0800
> >
> > "Alexey Kuznetsov's latest patch to "libpcap" lets it read the old
> > format, as well as the new format *with* a changed magic number.
> > Capture files written by RH 6.1 would have to have their magic number
> > changed to 0xa1b2cd34, in the byte order of the host on which they were
> > written, in order to allow them to be read by the latest Kuznetsov
> > "libpcap", and files written by that "libpcap" won't be readable by the
> > old "libpcap" or the RH 6.1 "libpcap", just sufficiently recent versions
> > of Alexey's patch."
>
> So, it seems like there would be two slighty diferent file formats:
> those that use 0xa1b2c3d4 (or 0xd4c3b2a1 in big-endian)
They use 0xa1b2c3d4 as the magic number on big-endian and little-endian
format, but write it out in the writing host's byte order; the rule
isn't "if it's 0xa1b2c3d4 it's little-endian and if it's 0xd4c3b2a1 it's
big-endian", the rules is "if it's 0xa1b2c3d4 it's in the byte order of
the machine reading the file, and if it's 0xd4c3b2a1 it's in the
opposite byte order from the one of the machine reading the file".
> the and those that use 0x1b2cd34 (or 0x34cdb2a1 in big-endian).
(Same endianness rules.)
No, there are *several* different file formats:
at least *three* that use 0xa1b2c3d4 - standard libpcap,
Kuznetzov's original libpcap, and some format Nokia came up
with, presumably used in some product of theirs;
at least *two* that use 0x1b2cd34 - Kuznezov's original fixed
libpcap, which had some debugging gunk in it (to debug some part
of the Linux kernel on SMP machines, I suspect), and his later
version, which removed that but didn't change the magic number.
> Are there any other diferences between them apart the magic number?
Yes. They differ in the length of the per-packet header:
standard libpcap has one format of per-packet header;
Kuznetzov's original libpcap, and his final libpcap, have
another;
his SMP-debugging version had another;
Nokia's has yet another.
The added length comes from additional fields.
There's also the AIX libpcap, which has the same per-packet header *and*
the 0xa1b2c3d4 magic number, but which
1) uses SNMP interface type values, rather than DLT_ values, in
the file header;
2) writes out files with seconds-and-nanoseconds, rather than
seconds-and-microseconds, time stamps.
> Could anyone shine some light on this matter, please?
If you write files with your own code, you should, by default, write out
files with:
a magic number of 0xa1b2c3d4;
the link-layer type as a DLT_ value;
the standard per-packet header that I described in my earlier
mail, including seconds-and-microseconds time stamps.
This means that
1) any program linked with the standard libpcap will be able to
read them;
2) any program linked with any version of Kuznetzov's libpcap
other than the first one will be able to read them (as he
changed the magic number, and treated files with the
0xa1b2c3d4 magic number as standard libpcap files);
3) Ethereal will be able to read them no matter *what* libpcap
it's linked with (as it has its own capture-file reading
library, which uses a bunch of heuristics to try to guess
which of the libpcap formats with the specified magic number
this is; the heuristics involve seeking and re-reading, so
they can't just drop into libpcap without some work, as
libpcap has to be able to read from pipes).
Kuznetzov's original libpcap is used in Red Hat 6.1, but 6.2 picked up,
as I remember, the final version. SuSE Linux 6.3 picked up the version
before that, so captures from that version can't be read by RH 6.2, and
captures from RH 6.2 can't be read by SuSE 6.3, but they can both read
standard libpcap captures.
Programs linked with the AIX libpcap won't be able to read them
correctly (they'll think the link-layer type is something other than
what it is, and will misinterpret the time stamps), but that's true of
captures from standard versions of tcpdump, or from Ethereal, or....
The same applies to whatever software Nokia did.
You could, I guess, add support to your program for writing captures in
AIX libpcap format as well, with a command-line option. We don't know
what the additional fields in the record header of Nokia's - it's 4
bytes of unknown stuff after the standard libpcap header - so Ethereal
can't write them, as we don't know whether their tool, whatever it might
be, would report errors or cause other problems if we don't put the
right stuff in those 4 bytes.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
