On Nov 20, 2003, at 5:22 AM, Martijn Schipper wrote:
My Windows Ethereal version 0.9.16 doesn’t read WildPackets AiroPeek
version 2.0 files.
Attached an AiroPeek 2.0 file.
As XML continues its inexorable march....
I don’t know the file format of AiroPeek, so I can’t see what is wrong.
What's wrong is that the file format changed substantially from what
previous WildPackets *Peek applications used. The new capture format
has:
what appears to be a small 12-byte binary header;
a pile of XML giving version information (file format, application,
etc.);
another 12-byte binary header;
another pile of XML giving information about the capture (time stamp,
time zone offset, media type, media subtype, link speed, packet count,
"domain" (whatever that is), data rates, and channels);
binary data that begins with "pkts", so it presumably contains the
packet data.
Does anybody have a solution?
If you could send us either
1) documentation on the file format, if WildPackets documents it
anywhere;
2) two of those captures (so we can try to guess what parts are
"template" and what parts are data), along with some form of printed
dissection of the captures from AiroPeek (so we can try to guess where
the frame data begins, and thus perhaps infer what per-packet headers
there are);
we could try to reverse-engineer the format if you can't send us 1) and
implement code to read it. I can't say when we'd be able to implement
that, though.
This would require an XML parser sufficient to parse the stuff in that
header; I don't know what free-software XML parsers are out there other
than libxml - which can, hopefully, be told to consume data from a
mallocated buffer.
It *looks* as if the first 12-byte binary header consists of:
"\177ver", as a string;
a 4-byte little-endian value that's the length of the XML blob that
follows the header;
00 02 00 00.
The second header consists of:
sess, as a string;
a 4-byte little-endian value that's the length of the XML blob that
follows the header;
00 02 00 00.
