0

I have a couple of pcap files where the capture length reported by Wireshark is larger than the actual capture length. The difference is 10 bytes, and I don't understand why it reports this higher number.

file reports the same value as Wireshark does in the Statistics->Summary dialog.

$> file out_20140207162250.pcap
out_20140207162250.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 100)

I can use tshark to give me the capture length for the packets that have a capture length shorter than the packet length to see what the actual size was.

$> tshark -r "out_20140207162250.pcap" -R "frame.cap_len < frame.len" -Tfields -eframe.cap_len | sort | uniq
tshark: The file "out_20140207162250.pcap" appears to have been cut short in the middle of a packet.
90

Looking into the file with a simple C-program, I can see that the snaplen in the pcap_file_header is really set to 100.

#include <pcap.h>

int main(int argc, char **argv) {

  FILE *pcapInputFile_p;
  pcap_file_header fileHeader;

  pcapInputFile_p = fopen(argv[1], "r");
  fread( &fileHeader,sizeof(pcap_file_header), 1, pcapInputFile_p );
  printf("%d\n",fileHeader.snaplen);  
  fclose(pcapInputFile_p);

}

I don't actually know how and with what tool this specific file was captured, but I am trying to find that out :).

Trying to repeat this with Wireshark 1.11.0 on my Windows machine, I set "Limit packet size" to 96. Wireshark reports each packet cut at 96, but in Statistics->Summary it's 100, i.e. 4 bytes more than I configured. OK, so now I set it to 106. I get 106 both per packet and in the Summary dialog!

So now I am intrigued... and it's Friday afternoon and I am trying to kill some time. I wrote a script to capture (with dumpcap 1.8.2) one single packet with a size greater than 1500, and output that to a file. During the time the script ran I downloaded a huge file, to get some large packets. The system was Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux. Here's a plot of configured versus actual snaplengths between 50 and 150 (pattern repeats up to 1500 at least). The shaded lines just shows that configuring 96 gives us 96 on this system. The biggest difference is 2 bytes, always less than what I configured!

Picture of configured versus actual capture length (need rep to post, not sure for how long it's stored)

So to sum up, why is there a x byte difference between reported capture length and actual capture length? Why sometimes? Why different for different systems/tools? If so, why? Is this a bug, or am I confused?

Thank you!

  • Paging @GuyHarris. – Spiff Feb 7 '14 at 17:37
  • What version of libpcap is this? There have been bugs in the handling of snapshot lengths in memory-mapped capturing on Linux in some versions. – user164970 Feb 7 '14 at 21:14
  • On the Windows machine, it's WinPcap 4.1.3. I will have to check for the other two, on a different computer now. I tried on this one, Mac OS X, dumpcap 1.10.2 compiled with libpcap 1.3.0 - Apple version 41 and here it works perfectly. What is "memory mapped capturing"? – bytesinflight Feb 7 '14 at 21:49
  • Disregard the last part, I googled :) Thnx. – bytesinflight Feb 7 '14 at 22:27
0

Answering my own question here, since what I found out since I asked the question "solves" it for me. It at the very least would have taken me much longer to understand this without the help of @GuyHarris who kindly left a comment above, so Thank you!

I spent some time compiling a couple of different versions of libpcap together with latest tcpdump. The results can be divided into three categories (bad, semi-bad and perfect), where the latest libpcap tested OK. Today, when I repeated the test on Windows with dumpcap and Wireshark I could not repeat this! I am not crazy, I swear!

Summary - this totally depended on the libpcap version. I did not find that the system, or any other software affected this. So people, upgrade your libpcap to save you from some frustration! :)

See picture here - Configured versus actual snaplength

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.