problem opening dumpfiles and capturing when built with libz 1.2.4

This issue was migrated from bug 4606 in our old bug tracker.

Original bug information:

Reporter: joh…@‍gma…
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: All
Platform: All
Version: 1.2.6

Attachments:

out.cap: Capture from tcpdump which wireshark can't read
libz.patch: Patch to show libz runtime version

joh…@‍gma… said:

Build Information: Version 1.2.6

Copyright 1998-2010 Gerald Combs <gerald@‍wireshark.org> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled with GTK+ 2.18.7, with GLib 2.22.4, with libpcap 1.0.1_pre20090812, with libz 1.2.4, with POSIX capabilities (Linux), with libpcre 8.0, without SMI, without c-ares, without ADNS, without Lua, without GnuTLS, without Gcrypt, without Kerberos, without GeoIP, without PortAudio, without AirPcap.

Running on Linux 2.6.32-tuxonice-r5, with libpcap version 1.0.1_pre20090812.

Built using gcc 4.4.3.

Wireshark is Open Source Software released under the GNU General Public License.

Check the man page and http://www.wireshark.org for more information.

Hi there,
I was trying to get a capture started, it seems that only one "sample" was captured. What I mean by this is, the first packet(s) get captured, all following aren't recognized. So I tried dumping with tcpdump and opening the resulting file with wireshark, but then it gave me this error:
The capture file appears to be damaged or corrupt.
(pcap: File has 1435526081-byte packet, bigger than maximum of 65535)

The file is not corrupted, tcpdump can read it. I have no idea why wireshark stopped working lately.

tcpdump: 3.9.8-r1 or 4.0.1_pre20090709, doesn't make a difference
libcap: 2.17 or 2.19, no difference either
libpcap: 1.0.1_pre20090812

Best Regards
Johannes Jeske

added uigtk version1.2 labels

Jeff Morriss said:

Can you attach (one of) the capture file(s)? You can mark it private if you'd like (then only core developers can access it).

joh…@‍gma… said:

Created attachment 4436 Capture from tcpdump which wireshark can't read

Jeff Morriss said:

Hmmm, Wireshark reads that file just fine for me (I tried both the SVN version on Linux x86-64, 1.2.1 on Linux x86-64, and 1.2.6 on Windows x86).

Admittedly on Linux I'm using libpcap 0.9.8 . It might take me a while to dig up a different libpcap version and I'm not sure why it would cause Wireshark to fail where tcpdump is OK. (Are tcpdump and Wireshark both using the same libpcap?)

joh…@‍gma… said:

Well, they should use the same libpcap. I'm going to try to compile the old version, which failed now. I'll see what I can do. If it's really the libpcap, it seems to be a bug with new versions of libpcap...

joh…@‍gma… said:

Okay, even with libpcap 0.98 it doesn't work. Any ideas?

Best Regards

Johannes Jeske

Jeff Morriss said:

Hum, no good ideas at the moment. A stab in the dark:

Try running Wireshark under Valgrind to see if there's some memory stomping going on?

Jeff Morriss said:

OTOH, 1435526081 == 0x559063C1 and there are plenty of occurrences of that number in the PCAP file.

Looks like that's the last 4 bytes of the 2nd packet (a DNS response pointing to www.heise.de).  That IP features prominently in this capture file.

Looking a bit further, the PCAP global file header says the snapshot length was 96 bytes.  But, looking at frame 6, for instance, it says that only 90 bytes were captured and Wireshark notes that the capture was truncated.  That's odd but it *shouldn't* cause any problems.  Hand-decoding the PCAP file up to the 7th packet *seems* to be OK to me.

Guy Harris said:

1) Wireshark doesn't use *any* version of libpcap to read pcap files - it has its own independent code to read capture files of all types, including pcap files; it (or, rather, dumpcap) only uses libpcap to capture live traffic.  libpcap isn't the cause of this issue.

2) Wireshark 1.2.6 has no problem reading this file on OS X or Windows XP; perhaps this is a problem with some library on your version of Gentoo, or a problem with Wireshark that doesn't prevent it from working with the versions of libraries on some OSes but that something about some library on that version of Gentoo reveals.

joh…@‍gma… said:

Valgrind didn't give any useful output, so there's obviously no problem with memory. Still I have no idea why wireshark doesn't work. Any ideas which gentoo package should be recompiled? I recently allowed all "testing" packages to be merged, maybe this is the cause. But I don't want to change that again, maybe just one package has to be an older version?

Best Regards

Johannes Jeske

Guy Harris said:

My guess is that this is a problem with libz. If so, I don't know whether it's a problem introduced in libz 1.2.4 (which apparently redid the gz* routines, which is what Wireshark uses to read files - even uncompressed ones - if it's built with libz) or a Gentoo-specific problem.

joh…@‍gma… said:

Thanks a lot, it WAS libz (or rather zlib on gentoo). So workaround is using an older version. Though it's a bug and I think it should be fixed.

Best Regards

Johannes Jeske

Guy Harris said:

Well, I downloaded libz 1.2.4 source, compiled and installed it on Mac OS X 10.6.2, and built top-of-SVN-tree Wireshark with it, and tried to read out.cap. It didn't have a problem.

So it's not as simple as "libz 1.2.4 is completely broken".

Guy Harris said:

However, if I download the 1.2.6 source and compile *it* with libz 1.2.4, it can't read the same capture file that top-of-tree Wireshark could read when it was compiled with libz 1.2.4.

In addition, if I do "make clean" on my top-of-tree source, and rebuild, it also can't read the same capture file.

Jeff Morriss said:

bug #4439 (closed) shows problems with zlib 1.2.3.7 too

Richard Brodie said:

The problem with the capture files is a zlib bug, now fixed upstream.

The live capture still stops after a few packets but that may be a little harder to pin down.

Vladimir Vasilenko said:

*** Bug #4625 (closed) has been marked as a duplicate of this bug. ***

Guy Harris said:

Does "upstream" in "The problem with the capture files is a zlib bug, now fixed upstream." mean "zlib.net"? The latest version they list is 1.2.4.

Richard Brodie said:

zlib.net are bit shy with beta versions, and it may not have been released when I last commented. It is fixed in 1.2.4.1 though.

http://zlib.net/current/beta/

Richard Brodie said:

Created attachment 4526 Patch to show libz runtime version

Patch to display runtime version for libz, as well as build version.

Stig Bjørlykke said:

Comment on attachment 4526 Patch to show libz runtime version

Committed revision 32502.

Anders Broman said:

1.2.5 is out, is that working? If so should we use it also in the windows build?
On a side note; does this improvement
>•Added inflateReset2() and inflateMark() functions, the latter to aid in random access applications  

make it possible to have random access now?

Peter said:

(In reply to comment #‍17)
> 1.2.5 is out, is that working?

I was able to load out.cap attached to this bug but there is bug #4708 (closed) now.

Jeff Morriss said:

Problem was in zlib: 1.2.4 doesn't work. 1.2.5 with some patches (already checked in) does work. Closing this bug.

closed

mentioned in issue #4625 (closed)