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

packets shown by tcpdump and wireshark

0

Hi I wanted to check if the sniffer application I'm using has zero packet loss. For that I have used tcpreplay to send a specific number of packets into the capture port. The number of packets shown by wireshark or tcpdump -r while opening the pcap file does not seem to be the same as the one shown by tcpreplay. Why is that?

asked 27 Jul '15, 00:07

jichu's gravatar image

jichu
11447
accept rate: 0%


One Answer:

1

Why is that?

There are many possible reasons:

  • packet loss on the network
  • packet loss on the switch mirror port (if you were using that)
  • packet loss on the sniffer system (high CPU/IO load, etc.)
  • bug in tcpreplay and/or Wireshark with the result that one of these shows wrong numbers
  • rather unlikely: TCP segment offloading on the sender

Regards
Kurt

answered 27 Jul '15, 15:46

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hi, thanks for the reply.. I checked with "iperf" there is no loss in network, and I use ESXi Virtual switch for the system, I don't think packet loss happens there. The sniffer software I use (netsniff-ng) shows no packet loss, so only option left is a bug and/or TCP segmentation offloading

(28 Jul '15, 00:04) jichu

So what Guest OS are you using where you run tcpreplay?

(28 Jul '15, 00:20) Christian_R

I use Ubuntu Server 14.04 LTS for both sniffer and for tcpreplay

(28 Jul '15, 00:50) jichu

Have you checked the counters with ifcongig or ethtool -S?

(28 Jul '15, 01:00) Christian_R

Yes, no packet drops shown in ifconfig eth1 and ethtool -s eth1 command

(28 Jul '15, 01:13) jichu

And tcpreplay shows more packets transmitted correctly then the tcpdump output? Is it still reproduceable?

(28 Jul '15, 01:16) Christian_R

Yes thats correct. I'm running one now, when its completed I can post the output

(28 Jul '15, 01:39) jichu

Hi

TCP replay output:

Actual: 612469500 packets (305393106000 bytes) sent in 10685.58 seconds. Rated: 28579928.0 bps, 218.05 Mbps, 57317.38 pps Statistics for network device: eth1 Attempted packets: 612469500 Successful packets: 612469500 Failed packets: 0 Retried packets (ENOBUFS): 0 Retried packets (EAGAIN): 0

Sum of all tcpdump -r output (using a script): 48861713

The script is used is :

#!/bin/bash
files=(/share/capture/job2/*.pcap) sum=0 for f in "${files[@]}" do output=sudo tcpdump -r $f 2> /dev/null | wc -l sum=$((output + sum)) done echo $sum

(28 Jul '15, 04:00) jichu

And what does capinfo tell you?

(28 Jul '15, 04:35) Christian_R

Same as tcpdump -r

(28 Jul '15, 04:45) jichu

Maybe it is something like that (as Kurt already noticed): packet loss on the sniffer system (high CPU/IO load, etc.)

And the difference is that Iperf and tcpreplay sends out the packets in different wave forms.

(28 Jul '15, 13:05) Christian_R
showing 5 of 11 show 6 more comments