This is our old Q&A Site. Please post any new questions and answers at

Hi all. Big fan, and user, of the 'shark, but haven't had a need to post in quite a while...

I have run into a strange problem - perhaps someone has some ideas. Here it is...

I'm in the U.S., and I'm working with colleagues in India, who are running wireshark on their workstations, and sending me the files when they are done. What I'm finding is the Wireshark files I receive are missing a significant portion of the capture, at the end of the file. For example, after capturing for 20 minutes today, the file I receive has packets spanning the first 6 minutes.

The packets that ARE in the file all look fine - no missing packets, timestamps are chronologically ordered, delta times between packets are all subsecond and reasonably spaced, etc. It appears to be a perfectly healthy trace file... Except that the last packet's timestamp is 14 minutes before they stopped capturing.

In a previous activity, we set up Wireshark to capture multiple files, creating a new one every 10 minutes. (I even saw their Capture Options screen - it looked correct.) When I received the resultant files, each of them was approximately 2 minutes long.

And... This is happening on more than one workstation.

Obviously, I'm limited in what I can do to troubleshoot, due to remoteness.

I'd love for someone to say, "I've seen this before", or something equally helpful.

thx all, feenyman99

asked 07 Nov '12, 10:25

feenyman99's gravatar image

accept rate: 25%

Is there a maximum file size imposed in addition to a maximum capture time duration? Maybe the max size is reached before the time duration has elapsed?

(07 Nov '12, 11:49) cmaynard ♦♦

You say they "send" the file.

Some questions:

  • How exactly do they send the file?
  • Is the file size of the transmitted capture file identical on both sides?
  • Did you calculate a MD5/SHA1 checksum of the capture file on both sides? Are the checksums identical?

Reason: The file might be truncated/modified while it is transferred to you. Example: If you use FTP and don't choose BINARY transfer mode, ASCII mode might be used, which might modify the capture file.


permanent link

answered 07 Nov '12, 10:56

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
accept rate: 15%

Kurt - Thx for the quick response!

Files have been transferred via 2 methods: NetMeeting File Transfer & Sharepoint.

I have compared file sizes, and they are the same on both sides. (I have not compared checksum's).

It seems that, when we expect Wireshark to create a file with "n" minutes' worth of traffic, the resultant file has only the first "less than n/2" minutes.

Yeah - I know... Weird. I've been using Wireshark/Ethereal for 10+ years, and haven't seen anything like this.

I was just hoping I'd get real lucky, and someone in this forum would have seen this.

Anybody else have ideas???

Thx all!!!

(07 Nov '12, 12:10) feenyman99
  • What is your Wireshark version in India and US (wireshark -v)?

(I have not compared checksum's).

please check them, just to make sure they are indeed identical.

Then I recommend to transfer the file in a ZIP container. If the ZIP container gets corrupted (truncated, modified, etc.), the ZIP tool will tell you. I use 7-Zip most of the time (

  • Is the output of the following command identical on both systems (india and US)? Are there frames missing at the end?

tshark -r input.cap -T fields -e frame.number -e frame.time_relative -e frame.time_epoch

(07 Nov '12, 13:24) Kurt Knochner ♦

Again... Thx Kurt for responding. I can execute those checks - I hope - when India folks wake up (it's 4:30am there now) and I can get some time from them.

HOWEVER... Is there any possibility that the capture buffer size is too small? Would that cause behavior like this??

Thx again...

(07 Nov '12, 15:08) feenyman99

Is there any possibility that the capture buffer size is too small?

I don't think so.

What is your Wireshark version and OS?

(07 Nov '12, 15:12) Kurt Knochner ♦

MY Wireshark, where the file is being READ, is version 1.5.6 (SVN Rev 40429 from /trunk-1.6), running on XP Pro Version 2002, Service Pack 3.

THEIR Wireshark, where the file is being WRITTEN... I must wait till I reconnoiter w/ the India folks to answer this.

After I asked about a possible buffer size problem, I did some reading and I agree that this is very unlikely. I gather that if the buffer were too small, I would see "missing" packets amongst the existing packets. I see none of this. Instead, the packets that are missing all belong after the last packet in the file.

(07 Nov '12, 16:31) feenyman99

MY Wireshark, where the file is being READ, is version 1.5.6

O.K. can you please try the latest stable version 1.8.3?

(08 Nov '12, 00:21) Kurt Knochner ♦

Kurt... the files are being captured and written on Windows XP, Wireshark version 1.0.5.

thx again for all ur help.


(08 Nov '12, 05:47) feenyman99

version 1.0.5.

a pretty old version. If there is no good reason to use that old version, I really recommend to use the latest official release 1.8.3. With that version you should see none of these problems.

thx again for all ur help.

Does that mean your problem is solved? If so, how?

(08 Nov '12, 05:54) Kurt Knochner ♦
showing 5 of 8 show 3 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 07 Nov '12, 10:25

question was seen: 1,860 times

last updated: 08 Nov '12, 05:55

p​o​w​e​r​e​d by O​S​Q​A