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

editcap fails to split large trace

0

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:

C:\Program Files\Wireshark>capinfos infile.pcap
File name:           infile.pcap
File type:           Wireshark/tcpdump/... - libpcap
File encapsulation:  Ethernet
Packet size limit:   file hdr: 65535 bytes
Number of packets:   5235627
File size:           91027900 bytes
Data size:           7257844 bytes
Capture duration:    1289414770 seconds
Start time:          Thu Jan 01 08:00:00 1970
End time:            Thu Nov 11 02:46:09 2010
Data byte rate:      0.01 bytes/sec
Data bit rate:       0.05 bits/sec
Average packet size: 1.39 bytes
Average packet rate: 0.00 packets/sec
SHA1:                7423f4a61fa1eece737579edd023b3243e9715c7
RIPEMD160:           8186ff80810036a867c046e686dc5d5137c9e031
MD5:                 2e725c970a09bedcc5de9aee0bc6e8e3
Strict time order:   False

asked 20 Dec '10, 00:05

dopplershift's gravatar image

dopplershift
1111
accept rate: 0%

edited 20 Dec '10, 01:09

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245


One Answer:

0

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's gravatar image

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

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.

(20 Dec '10, 16:54) dopplershift

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:?

(20 Dec '10, 19:44) Guy Harris ♦♦

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.

(20 Dec '10, 22:45) dopplershift

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

(20 Dec '10, 22:45) dopplershift

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?

(20 Dec '10, 23:26) Guy Harris ♦♦

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.

(20 Dec '10, 23:26) Guy Harris ♦♦

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.)

(20 Dec '10, 23:26) Guy Harris ♦♦

Could you post the output of:

tshark -nr <file> -R "frame.number>=218128 and frame.number<=218129" -V -x

(21 Dec '10, 02:32) SYN-bit ♦♦

editcap -v -c 50000 infile.pcap outfile.pcap

and

editcap -v -r infile.pcap outfile.pcap 0-218128

(21 Dec '10, 18:06) dopplershift
showing 5 of 9 show 4 more comments