0

I am using a python tool to generate packets in one VM and I capture them in my program running as a linux process in another VM. Both the VMs are ubuntu and they are running on the same subnet. I notice that some of the packets get dropped in my program. What is the best tool to know where the packets are dropped?

I see that RcvbufErrors in netstat output gets increased as I send new packets.

# netstat -us
IcmpMsg:
    InType0: 14
    InType3: 1493
    InType5: 204
    InType8: 54
    InType13: 5
    InType17: 5
    OutType0: 54
    OutType3: 645946
    OutType8: 584
    OutType14: 5
Udp:
    7686124 packets received
    646545 packets to unknown port received.
    33928069 packet receive errors
    7157259 packets sent
    RcvbufErrors: 33928069
    IgnoredMulti: 345772
UdpLite:
IpExt:
    InMcastPkts: 4
    InBcastPkts: 363522
    InOctets: 13243409806
    OutOctets: 8445992434
    InMcastOctets: 144
    InBcastOctets: 114457552
    InNoECTPkts: 100191590
    InECT0Pkts: 143
Jim Lewis
  • 43,505
  • 7
  • 82
  • 96
Adel
  • 1
  • 1
  • 3
  • 1
    By its very nature, UDP is unreliable. Packets could be getting dropped from anywhere. You have to sniff the network traffic, such as with Wireshark, to see if it is on the sending side, the receiving side, and anywhere in between. Possible duplicate of [UDP packet drops by linux kernel](https://stackoverflow.com/questions/10899937/). Most likely, the receiver is simply not receiving packets as fast as the sender is sending them, so the receive buffer fills up and discards packets. – Remy Lebeau Sep 05 '17 at 20:12
  • @Jim the packets are received in receiver VM as the netstat output shows but the receiving buffer gets full before the application can consume it – Adel Sep 06 '17 at 16:54

1 Answers1

0

Well, if you think that you need to find out where some packets get dropped, this might not be useful since you already know that at least RcvbufErrors figure is growing. This means that the NIC is able to deliver the packets to the kernel but the latter is unable to deliver the packets to the application, obviously, because a fixed-size receive buffer gets full faster than the application could read the data out (or just flush it).

So, I'd say such a result just gives an impression of poor application design. Perhaps, you should consider some good technique to enhance packet capture in your application so that more packets are captured/examined/dropped per second. A good example is PACKET_MMAP Rx ring which has an exhaustive description and is widely used in libpcap-based applications. The latter aspect makes it indeed reasonable to use wireshark or just tcpdump instead of your hand-made app to inspect the real capture rate, etc.

  • I could improve the performance significantly by increasing the receiving buffer size by using setsockopt with SO_RCVBUF option and passing a larger value for size but there is still some bottleneck in the application. Thank you for your comment. – Adel Sep 06 '17 at 16:56