RE: gzip and tcpdump...

["Fulvio Risso" <fulvio.risso () polito it>]

> -----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