0

I am trying to find the number of lost packets in the network.

I have 2 devices say DeviceA and DeviceB. IP addresses are respectively DeviceA : 192.168.0.104 and DeviceB: 192.168.0.105.

In order to start Wireshark captures at the same time, I send a start command by another Device C and then stop the captures again after 5 minutes. During the capture, I sent a 300MB file from DeviceB to DeviceA over Windows file sharing, which uses TCP.

I saw that both pcap files starts with the SAME TCP packet and ends with the same TCP packet. However when I filter the capture in DeviceA with ip.src==192.168.0.105, I receive 165.367 packets. When I apply the same filter in DeviceB, I receive 163.315 packets. Meaning that DeviceA says it received more packets than the DeviceB has sent.

DeviceA pcap has 19468 NBSS packet, however DeviceB pcap has 73629 NBSS packet. How is that possible, is this a normal behaviour or am I missing something?

Improve this question
3
  • There can be duplicate packets sent from B to A due to loss. In the receiver side you should be seeing those. Check out this page: wiki.wireshark.org/DuplicatePackets. You can turn off the display of those packets as explained in the page. The problem is may be B is showing only the number of successful transmissions and A is showing all the packets it received from B. As I said 'may be', this is just an hypothesis. But worth to give a shot :)
    – naïveRSA
    Jan 16, 2020 at 13:37
  • Thx for help. I checked the filter suggested in that page. After using the filter in both pcap files, pcap of A still has more packet than B after removing duplicate_ack and retransmission.
    – I.K.
    Jan 16, 2020 at 13:50
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer.
    – Ron Maupin ♦
    Dec 17, 2020 at 15:10

3 Answers 3

Reset to default
1

I found some resources about this. If you are trying to compare two pcap files in two endpoints to analyze network traffic, packet numbers may not match in both ends. If received packet number of your receiver end is greater than the sent packet number of your sender, this may be because of GRO and LRO implementation of the NICs. Some NIC may have a feature to aggregate multiple incoming packet to a single stream to reduce cpu time per packet overhead. For further information check : GRO, Generic Receive Offload, Linux Networking Stack

Improve this answer
0

Despite you used Device C to syncronize packet capture on both Devices it is nearly impossible to simultaneously start and stop capture, commands might reach one of the devices earlier than other one. I would recommend you to compare particular TCP sessions which can be identified by src and dst port numbers or "tcp.stream" field in Wireshark.

Improve this answer
1
  • Thx for help. I was inspecting the same session in both client and server. I am using the 5-tuple filter (ip1,port1,ip2,port2,protocol). However, still the deviceA shows 2000 more packet than deviceB.
    – I.K.
    Jan 17, 2020 at 6:49
0

TCP may lose some segments when the interconnect or the destination is slower than the source - that is by design and required for congestion control. Congestion control continuously tries to ramp up the send window until packet loss is detected and then throttles it again.

Improve this answer
2
  • Thx for help. Problem is, in my A.pcap file there are 165.367 packets that are sent from 105 and recvd by 104, however in B.pcap file there are 163.315 packets that are from 105 and recvd by 104. Its like some packets are reproduced in the air. I want to learn the reason behind this.
    – I.K.
    Jan 17, 2020 at 12:43
  • @I.K. There may be host issues or host-related issues causing that - these are off-topic here, unfortunately. If you're using a LAG trunk in between the hosts, some frames may be duplicated as well.
    – Zac67 ♦
    Jan 17, 2020 at 12:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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