tcpdump mailing list archives
RE: gzip and tcpdump...
From: "Fulvio Risso" <fulvio.risso () polito it>
Date: Wed, 26 Feb 2003 08:36:02 +0100
-----Original Message----- From: owner-tcpdump-workers () sandelman ottawa on ca [mailto:owner-tcpdump-workers () sandelman ottawa on ca]On Behalf Of Rob Braun Sent: Wednesday, February 26, 2003 02:16 To: Guy Harris Cc: tcpdump-workers () tcpdump org Subject: Re: [tcpdump-workers] gzip and tcpdump... 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.
Some discussions about pcap file format were on this mlist in Nov 01. I believe that a new pcap_dump_open_ex() should be the best choice. You can put there a parameter that allows you specifying the file format, so you can implement whatever you want. fulvio
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 - 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)