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.
[Yes, this processor overhead won't help with packet-loss, but at least in my application (a "network flight recorder") the ( processing_power / network_load ) * ( running_time / storage_space ) value is sufficiently high I can afford to / *need* to, compress the pcap files.] If I work up a patch or two, what are the chances that they'd be merged into an official release (0.7?) ? I believe I could implement the changes in a backwards compatible, transparent fashion, using the filename to automatically switch on zlib (i.e. if fname ends in ".gz", use zlib i/o). (Indeed, for reading, it seems zlib will automatically read uncompressed data.) Q's: 1. is having the save file FILE pointer opaque intentional? i.e. pcap_dumper (just a cast FILE pointer) is passed to pcap_dump as a (u_char *) (this is not documented, BTW :-) (yes, I could/should provide a patch, and will do as part of the above work) 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). - 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? - is there a cleaner way? -- Ben Low "The truth is more important than the facts." - Frank Lloyd Wright - 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
