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

Capture file error

0

Wireshark Virtual machine capture seems to be corrupt. I'm trying to debug a performance isse and keep recieved the following error. "The capture file appears to be damaged or corrupt. (pcap: file has 65590-byte packet, bigger than the maximum of 65535". Even though wireshark says the capture is correct, the system appears to be functioning propoerly, i.e it is transferring data to a backup server. The wireshark version is 1.4.5. Can anybody point out what I might be doing wrong? I'm capturing in promiscuous mode with a buffer size of 2 megabytes with update list in real time not selected.Tthe system running Wireshark is using a VMware vmxnet3 netowrk device.

asked 18 Apr '11, 06:52

jadechen's gravatar image

jadechen
1111
accept rate: 0%

My system is a 64 bit version of Windows R2 sp1 and I tried the "old Stable release 1.2.16" and still got the same wireshark crash. Any other suggestions would be appreciated. I'm trying to debug a backup applcations from a VM to a Physical system where the windows size always is in the 500 byte range (so it's ver slow), but in all my traces I never see the TCP options fields either set Sel Acks, or Windows scaling.

(18 Apr '11, 07:34) jadechen

Can you provide the capture via a bug report?

See Help ! About Wireshark ! Folders to see the directory in which the capture files are stored.

Or alternatively: use dumpcap to do the capture (using -w to specify the output file). (I'm presuming that an error will be reported when Wireshark or capinfos tries to read that file).

(18 Apr '11, 07:46) Bill Meier ♦♦

Trying to figure out how to add a bug. I think I have the capture file called wiresharkXXXXa00800. I looked through the current bug list and didn't see anything that looked familiar.

(18 Apr '11, 08:45) jadechen

2 Answers:

0

There's a significant problem with the most recent Wireshark 1.4.5 release.

See: Bug 5837

Altho your problem sounds like something different, please try using Wireshark 1.4.4 to see if the problem still persists.

(Windows 32-bit Wireshark 1.4.4 can be downloaded @ Windows Wireshark 32 bit 1.4.4)

If the problem persists with Wireshark 1.4.4, please file a bug report @ bugs.wireshark.org attaching a (short) capture file showing the problem.

If necessary, the attachment can be marked private so only the Wireshark core developers will have access.

answered 18 Apr '11, 07:06

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850
accept rate: 17%

edited 18 Apr '11, 07:24

0

Are you transferring the file by FTP from the system on which you created it to a system on which you want to view it in Wireshark? If so, please make sure you use binary mode, otherwise some magic is done on what FTP believe are line endings, but is in fact just binary data.

answered 18 Apr '11, 13:54

SYN-bit's gravatar image

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

Unfortunately I wasn't using ftp. the Crash occurs during collection. I turned update in real time and tried various buffer sizes. During a capture, I see the capture hand, i.e. stop collecting packets. When I the stop the capture I get the message about the 65590 to big error.

I've tried to enter a bug report but the process in not intuitively obvious to the casual observer. The system rejects what I put something in hte "named tag" field or when I hit commit on bugzilla.

Today, I'm going to collect with a fluke and try to use wireshark for the analysis.

(19 Apr '11, 04:33) jadechen

Can you give some more details on your capture setup? Is the Wireshark VM the one receiving/transmitting production traffic as well, or did you set up a dedicated capture VM that captures traffic of the production VM? I suspect you might have large send offload trouble if you are in fact capturing on the same machine that sends/receives the production traffic. I could verify this if I know your capture scenario a little better.

(19 Apr '11, 05:10) Jasper ♦♦