tcpdump mailing list archives
Re: gzip and tcpdump...
From: Rob Braun <bbraun () synack net>
Date: Tue, 25 Feb 2003 17:16:21 -0800
On Tue, Feb 25, 2003 at 12:09:46PM -0800, Guy Harris wrote:
or in libpcap directly ? (via zlib)That could probably be done, given that libpcap files are written purely sequentially. Having libpcap *require* zlib would probably not be a good idea (Ethereal, for example, supports reading gzipped files if you have zlib, but if you have a system without zlib, Ethereal can still be compiled, it just can't read gzipped files).
I'm looking at the code with the possibility of implementing this, and wanted to ask a few questions on how you see gzipped file support interfacing with libpcap. So, the reading of gzipped pcap files is relatively simple, because libpcap can detect if the file is gzipped or not and do the Right Thing. For outputting gzipped files, pcap_dump_open() does not specify the type of output file desired, since the concept of the type of file is something new. Ideally, API compatibility would be kept, and the pcap_dump_open() call would not be modified to take an argument specifying the type of output file. Do you see a new pcap_dump_zopen() or similar call being added, or should pcap_dump_open() still be the only entry point for dumping, and just look at the filename to dump to. If the filename we're dumping to is "*.gz" then output a compressed stream? We could also play other tricks with the filename passed to pcap_dump_open(), but this seems a little nonintuitive. Also, pcap_file() returns a FILE *. Would you see this function still needing to work for gzipped output files? pcap_dump()'s first argument appears to be assumed a FILE *. It looks like it needs to be opaque data to the user, but is it safe to break the assumption that this is a FILE *? I'm going to assume that we can ignore any users of struct pcap_sf's rfile element, since that is an "internal" data structure of sorts. If not, that would be good to know as well. Ideally, libpcap would be extended in a way that abstracted the writing of the exact file, allowing for arbitrary file output. Things like pcap_file() expose the underpinnings of the current libpcap implementation, and would you expect these to be preserved, or carried into the future? Rob - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe
Current thread:
- gzip and tcpdump... rmkml (Feb 25)
- Re: gzip and tcpdump... Matt Bing (Feb 25)
- Re: gzip and tcpdump... Guy Harris (Feb 25)
- Re: gzip and tcpdump... Darren Reed (Feb 26)
- Re: gzip and tcpdump... Guy Harris (Feb 26)
- Re: gzip and tcpdump... John Hawkinson (Feb 26)
- Re: gzip and tcpdump... Matt Bing (Feb 26)
- Re: gzip and tcpdump... Guy Harris (Feb 25)
- Re: gzip and tcpdump... Matt Bing (Feb 25)
- Re: gzip and tcpdump... Rob Braun (Feb 25)
- RE: gzip and tcpdump... Fulvio Risso (Feb 25)
- <Possible follow-ups>
- Re: gzip and tcpdump... Maik Pfeil (Feb 26)
- Re: gzip and tcpdump... arbon (Feb 26)