Re: gzip and tcpdump...

[Rob Braun <bbraun () synack net>]

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