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 |
One Answer:
You say they "send" the file. Some questions:
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. Regards answered 07 Nov '12, 10:56  Kurt Knochner ♦ 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
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 (7-zip.org).
(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
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
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. feenyman99 (08 Nov '12, 05:47) feenyman99
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.
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 |
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?