Hello Guy,
I couldn't find the file format in the AiroPeek documentation :-(
I saved the same file as an .rtf and .cvs file. I hope that helps. Let
me know if you need more information.
Martijn Schipper.
-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
Sent: vrijdag 21 november 2003 1:10
To: Martijn Schipper
Cc: ethereal-dev@xxxxxxxxxxxx
Subject: Re: [Ethereal-dev] Ethereal 0.9.16 doesn't read AiroPeek 2.0
files
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.
******************Legal Disclaimer**************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email help@xxxxxxxxxxxxxxxxxxx, and delete the message. Thank you."
****************************************************************
Attachment:
11g-bug-gw-smc.zip
Description: 11g-bug-gw-smc.zip