This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

capture file appears to be damaged or corrupt

0

The capture file appears to be damaged or corrupt. (pcap: File has 65706-byte packet, bigger than the maximum of 65535)

Hello, I am having an issue when trying to debug some voip calls. I capture the errors but the wireshark file is always corrupt with the error at the top of my post. I have tried using the wireshark GUI and also dumpcap using the following string

C:\Program Files\Wireshark>dumpcap -b filesize:50000 -wdebug.pcap

All files that i create are corrupt, even if I set dumpcap to create only a 5mb file this shows as corrupt. I have tried using Wireshark version 1.6.4 and 1.6.5.

The operating system is Windows 2008 64 bit R2 on VMWare. UAC and Windows Firewall are turned off

has anyone ever seen this issue?

asked 09 Feb '12, 07:16

processflows%20support's gravatar image

processflows...
1111
accept rate: 0%

edited 09 Feb '12, 07:18

grahamb's gravatar image

grahamb ♦
19.8k330206


3 Answers:

2

Did you capture the packets on the same system as where you are trying to view them in Wireshark? If not, how did you transfer the file from the capturing system to the Wireshark PC?

Most times I have seen this message, the files were transferred by FTP, but in ASCII mode instead of BINARY mode. This will mangle the file (as different systems use different line endings and FTP in ASCII mode tries to change byte sequences that look like line-endings).

So if you did transfer the file with FTP, please enable BINARY mode before sending the file over.

answered 09 Feb '12, 09:07

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

0

It seems like you might have a version of libpcap (winpcap) that has been modified. You should not see captured packets longer than 65535 bytes. Try reinstalling winpcap.

Alternatively, if you have an intentionally modified version of winpcap (perhaps one that supports larger packets), you'll need to adjust the following:

wiretap/libpcap.c, lines 756-771:

if (hdr->hdr.incl_len > WTAP_MAX_PACKET_SIZE) {
    /*
     * Probably a corrupt capture file; return an error,
     * so that our caller doesn't blow up trying to allocate
     * space for an immensely-large packet, and so that
     * the code to try to guess what type of libpcap file
     * this is can tell when it's not the type we're guessing
     * it is.
     */
    *err = WTAP_ERR_BAD_FILE;
    if (err_info != NULL) {
        *err_info = g_strdup_printf("pcap: File has %u-byte packet, bigger than maximum of %u",
            hdr->hdr.incl_len, WTAP_MAX_PACKET_SIZE);
    }
    return -1;
}

and wiretap/wtap.h lines 308-313:

/*
 * Maximum packet size we'll support.
 * 65535 is the largest snapshot length that libpcap supports, so we
 * use that.
 */
#define WTAP_MAX_PACKET_SIZE            65535

answered 09 Feb '12, 08:54

multipleinterfaces's gravatar image

multipleinte...
1.3k152340
accept rate: 12%

Thanks for the replies, I will get them to uninstall Winpcap. We have uninstalled and reinstalled wireshark but I am wondering if that also fully uninstalled/reinstalled winpcap at the same time. So I will uninstall Winpcap first, then wireshark, do a reboot and then reinstall from a fresh download. all software is direct download from the website with no modifications.

I dont think its the FTP issue as the files on the machine itself also seem to be corrupt. I did consider unusual partitioning on the server but it seems to be standard NTFS.

(13 Feb '12, 02:57) processflows...

Make sure your installer isn't getting corrupted during the download. It's unlikely, but you should probably do the verification anyway, given the nature of your problem. The 1.6.5 signature is available in the signatures file. The latest signatures file can always be found on the downloads page.

(13 Feb '12, 12:59) multipleinte...

0

Updating to the latest version 1.12 (at the moment) resolved the issue for me

answered 11 Sep '14, 13:57

Tesla's gravatar image

Tesla
1
accept rate: 0%

Perhaps Windows was doing TCP segmentation offloading, and delivered packets that actually were reassembled from multiple network packets and that were larger than 65535 bytes. 1.12 increased the maximum packet size to 262144 bytes, and thus didn't complain about those larger packets.

(12 Sep '14, 13:22) Guy Harris ♦♦