> I'd like to propose an extension to the libpcap save-file functionality
> - namely to support zlib's compressed file i/o. i.e. write gzipped pcap
> files.
Gzipped pcap files are, I guess, better than a poke in the eye with a
sharp stick, but it's not as nice a file format as, say, the compressed
Sniffer format, for one simple reason:
There is no upper bound, as far as I can tell, on the distance
between an earlier byte in the compressed file and a later byte
whose uncompressed value depends on that earlier byte.
Compressed Sniffer files consist of independently-compressed chunks, so
that only the data in a chunk is needed to uncompress the chunk - you
don't need the data in earlier chunks in order to decompress a chunk.
This makes no difference if you're accessing the file sequentially. It
makes a *big* difference if you're accessing it randomly, as, for
example, Ethereal does. Ethereal can reasonably efficiently read
compressed Sniffer files randomly; however, it can't at all efficiently
do random reads of gzipped files.
It might be nice to come up with a compressed file format more friendly
to random-access readers (although I wouldn't say that we should do that
*instead* of adding zlib support, unless we can come up with such a
compressed file format, and an implementation of it, quickly).
> 2. Is there any neat way of inserting timestamps into pcap files? (I want to
> record the start and end of trace times, which aren't neccessarily the
> times of the first/last packets).
That's something that I think would be best done with a new libpcap
format. The start trace time could be written to the file header, and a
special trailer record - different from a record containing a packet -
could contain the end trace time.
> - I've found that writing empty (header only, zero payload) pcap records to
> the file crashes tcpdump (at least 3.4a6). Writing a one-byte payload
> doesn't crash tcpdump, but is there anything else I should be aware of?
Presumably the one-byte payload would be treated by tcpdump - and any
other program that reads libpcap files - as if it were a packet; that
would probably not be a good thing (even if the only side effect were to
have the program complain about two malformed packets).
-
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
