I have an 88Mb trace file that is proving too large for wireshark to handle on my machine. I've tried splitting it up into smaller files, but editcap keeps stopping after packet 218,128. If I try to use editcap to get any packets over 218,128 I just end up with an empty trace. Any ideas what could be happening? Here's some info on the trace file: asked 20 Dec '10, 00:05  dopplershift edited 20 Dec '10, 01:09  SYN-bit ♦♦ |
One Answer:
Looks like your file is corrupt somehow. First of all, it has a duration of more than 40 years. But most important, the data size is smaller than the file size, which is impossible when the packet size limit is 65535. How did you transfer this file from the capture location to your windows system? If by FTP, did you use binary mode? answered 20 Dec '10, 01:13 SYN-bit ♦♦ showing 5 of 9 show 4 more comments |
Haha, yeah, thanks SYNbit. I noticed the timestamps and just assumed it was a mistake somehow (I'm not sure how wireshark gets this info, but I thought maybe the computer's clock had been reset while capturing?).
Unfortunately, it wasn't me who did the capture. And I'm not sure how it was transferred to our system... most likely copied and pasted via remote desktop (I'm in Perth and the site is in Melbourne). I'll try and get some answers to these questions.
In the meantime I'm just looking at the first 218,128 packets (about 15mins)... trying to find anything unusual.
Thursday, January 1, 1970, 00:00:00 UTC was Thursday, January 1, 08:00:00 local time in Perth, and is a time_t value of 0, so the time stamp of the first packet in the capture is probably bad.
Does editcap print anything before it stops?
If not, what happens if you run tshark on the file and, if possible, send the standard output to NUL:?
If I ask editcap to split the file into uniformly sized pieces, it prints out "Packet: 1","Packet: 2", up to "Packet: 218128" and then just stops.
If I ask editcap to put a range of packets into a new file it says "Add_Selected: 0-218128" then "Inclusive ... 0, 218128" and then stops.
Running tshark (just with -r)on the file just spits out packet info from packet 1 onwards until it starts sayong "252448 -1289413907.163060 -> Ethernet [Malformed Packet]" etc. I missed when this transition occurred, but presumably it was at 21,8129. It took a good 6 or 7mins to get there though.
Running tshark and sending the output to nul just hangs the cmd window for an unknown amount of time.
So, malformed packets hey? What does this mean and why does it break editcap?
Thanks again
When you say "If I ask editcap to split the file into uniformly sized pieces, it prints out "Packet: 1","Packet: 2", up to "Packet: 218128" and then just stops.", what command-line arguments did you pass to editcap? Was it a "-c" argument?
When you say "If I ask editcap to put a range of packets into a new file it says "Add_Selected: 0-218128" then "Inclusive ... 0, 218128" and then stops.", what command-line arguments did you pass to editcap?
The transition in TShark occurred at packet 252,448, because it said so.
252448 != 218128, so it's not clear that editcap's problem is the same as TShark's problem. TShark's problem is reported by a packet dissector; editcap doesn't do any packet dissection.
Is the unknown amount of time greater than, or less than or equal to, 6-7 minutes? If it's about 6 or 7 minutes, the command window probably isn't hanging - it's probably just running TShark, which is doing the same work that it did when you didn't redirect the output. (It'd probably take less than 6-7 minutes, though, as it's sending the packet dissection to the null device rather than to the cmd.exe window.)
Could you post the output of:
tshark -nr <file> -R "frame.number>=218128 and frame.number<=218129" -V -x
and