Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Compilation error Red Hat 3.4.3-9.EL4

From: Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx>
Date: Fri, 29 Apr 2011 13:36:45 +0200
On Fri, Apr 29, 2011 at 12:55:34AM -0700, Guy Harris wrote:
> On Apr 29, 2011, at 12:52 AM, Jakub Zawadzki wrote:
> 
> > Actually we still can do transparent access, but only when BLOCK is not inside
> > middle of byte.
> 
> Does that mean "we can still do fast random access to all gzipped files, but we have to change the way we choose when to start a new block", or does it mean "we can't do fast random access to some gzipped files"?

Sorry, don't know.

In *one* pcap file (ratio: 1.187):
  I have 2346 blocks (avg. every 37KB) from which 268 (avg. every 330KB) has bits=0.
  330 KB is still below SPAN constant (1MiB).
  (I can send C program to calculate these values for given gzip file)

But honestly, I don't care, if someone need it he can:
 1/ update zlib.
 2/ Write his own compressor and pass to deflate(..., flush):
     a/ Z_FINISH (and write new gzip header -- wiretap will always make a fast seek point).
	              And random access will work also without inflateSetDictionary.
     b/ Z_FULL_FLUSH, Z_SYNC_FLUSH (which should align block to byte boundary) every N bytes like he want (but N >= SPAN)
                  By using Z_FULL_FLUSH it should also be possible to
                  have random access without inflateSetDictionary.

> Note that we also use inflateSetDictionary(), which appears to have been added in 1.2.2.1 (31 October 2004).

I'm aware, should I commit patch for it? (or wait when wiretap fails to build to someone?)

Btw. from zlib page:
  Version 1.2.3 (July 2005) eliminates potential security vulnerabilities in zlib 1.2.1 and 1.2.2, so all users of those versions should ***upgrade immediately***

So maybe it's good (read: safer for user) if wireshark fails to build with zlib support? :-)