-Original Message-
From: Zemer Margolin [mailto:[EMAIL PROTECTED]
Sent: luned 29 novembre 2004 13.06
To: [EMAIL PROTECTED]
Subject: RE: [WinPcap-users] Pcap file format
Gui,
Thanks for your help and quick response.
I believe the information at
http://analyzer.polito.it/docs/advanced_man/how_to/add_new_lff.htm
Would help us develop the converter.
2 more question if I may:
1. The new PCAP format allows additional private fields in a TLV
format, is there a way to do so in the existing format?
2. Are there any more specification documents you can send me their links?
Please note that the doc you're referring to is related to an old version of
Analyzer, which is going to be discontinued. And Analyzer 3.0 does not plan
to have a format converter.
Please follow Guy's suggestion, if possible.
Cheers,
fulvio
zemer Margolin
Tel: +972-3765-7571
RADCOM
-Original Message-
From: Guy Harris [mailto:[EMAIL PROTECTED]
Sent: Monday, November 29, 2004 10:46 AM
To: [EMAIL PROTECTED]
Subject: Re: [WinPcap-users] Pcap file format
Zemer Margolin wrote:
I am currently working on a converter that converts captured
packets from one
format to another.
One way to do that might be to contribute to Ethereal:
http://www.ethereal.com/
code to read the format from which you're converting - Ethereal has a
limited ability to read from some RADCOM captures, but it's very far
from complete.
Unfortunately, I wasn't able to find any document describing
the PCAP file format.
Not a structure in a programming language, but a specification document.
The only document I found is
http://custom.lab.unb.br/pub/net/libpcap/doc/pcap.html
But it isn't fully compatible.
Well, the page at
http://analyzer.polito.it/docs/advanced_man/how_to/add_new_lff.htm
gives libpcap format as an example, although there are a few errors:
1) File Length is actually nominally Significant
Figures, which
would, in theory, be the accuracy of time stamps, but, in practice, it's
always zero and gives no information;
2) Future Applications is actually Snapshot Length,
which is the
maximum number of packet data in any of the records of the file - or a
value greater than or equal to that maximum, and is often 65535 (some
software might use it to allocate a buffer into which to copy the packet
data);
and also:
1) Time Zone is often 0, so it can't be relied on to contain the
offset of the time zone, at the location of the capture, from UTC in
seconds;
2) Link Type shouldn't use the values 11, 12, 13, or 14
- there are
other values that should be used for those purposes - and has some other
values that are available.
Note, however, that the not fully compatible format described in the
page you found - or, in a more up-to-date form, at
http://www.tcpdump.org/pcap/pcap.html
will be used at some point in the future, so code that reads the current
libpcap format won't be able to read all libpcap files in the future.
Note that if you implement code to read the files in question in
Ethereal, code to write libpcap format already exists, and code to write
the new libpcap format will be added in the future, so you won't have to
worry about that.
Also, if it's OK if the application in question uses libpcap/WinPcap, it
could use the libpcap/WinPcap routines to write the capture file.
==
This is the WinPcap users list. It is archived at
http://www.mail-archive.com/winpcap-users@winpcap.polito.it/
To unsubscribe use
mailto: [EMAIL PROTECTED]
==
==
This is the WinPcap users list. It is archived at
http://www.mail-archive.com/winpcap-users@winpcap.polito.it/
To unsubscribe use
mailto: [EMAIL PROTECTED]
==
==
This is the WinPcap users list. It is archived at
http://www.mail-archive.com/winpcap-users@winpcap.polito.it/
To unsubscribe use
mailto: [EMAIL PROTECTED]
==
