I have polled asynchronously a SNMP device in a simulated network using a java file, written with SNMP API. In a 30 seconds of polling time, I have sent around 350000 V1 Get requests.
My SNMP API listener showing that all the request have been sent and got success response for each request. But when I capture the packets using wireshark, it is not showing that all the packets are sent. When I check the request id of the snmp packets in wireshark,I could able to find out that the last request's requst id is same to the total number of packets sent by SNMP API. But request id of some other SNMP packets are missing in the wireshark.
For a 1 second polling, all the packets are captured in wireshark successfully. But when the polling time is increased, packet missing is occurred. For a 30 second polling, 350k requests, wireshark missed around 3k requests. If my API showing that 350k requests was sent, the first request id in wireshark is 1 and the last request id is 350k. But in between 1 and 350k, some requests are missing in wireshark.
Is there any limitation for wireshark like that it can capture only a particular number of packets per second?
Why this scenario occurred? Please help me to figure out this.
Thanks in advance.
asked 20 Sep '15, 21:35
edited 21 Sep '15, 06:33
Then you're running with a version of the Linux kernel with support for versions 1 (TPACKET_V1), 2 (TPACKET_V2), and 3 (TPACKET_V3) of the "turbopacket" memory-mapped capture mechanism and a version of libpcap that only supports versions 1 and 2.
TPACKET_V3 is a LOT better than TPACKET_V1 and TPACKET_V2 for packet capture; it makes MUCH more efficient use of the kernel capture buffer space. Libpcap 1.1.1 makes better use of the TPACKET_V1/TPACKET_V2 mechanism's buffer space than did even older versions, but that's still not enough to make it work really well.
If you could download, for example, the libpcap 1.7.4 source, compile it, install it, and rebuild Wireshark from source, linking it with the installed version of libpcap, that will probably drop a lot fewer packets, as it'll be using TPACKET_V3 - it might even be able to capture the fast burst of traffic (11666 packets per second!) without dropping packets. A worst-case scenario for TPACKET_V1 and TPACKET_V2 is a lot of small packets - each of the slots in the kernel's buffer for TPACKET_V1 and TPACKET_V2 can hold only one packet, no matter how small the packets are, so small packets waste a lot of space, whereas a slot for TPACKET_V3 can hold as many packets as will fit in the slot, and the smaller the packets, the more will fit.
answered 21 Sep '15, 00:58
Guy Harris ♦♦