packets dropped by kernel

[g18z0n]

i'm curious about the "packets dropped by kernel" count on the outputs, how bad it actually is?

i tried two different adapters ones uses the ath9k_htc driver and the other rtw88 both in-kernel versions, also tried on a rpi4b with kernel 6.6lts and on a PC with manjaro linux with kernel 6.12.

on all cases i have a lot of dropped packets but a higher number are captured and i was able to get PMKID and responses.

so is it normal to have a lot of dropped packets? what does it mean? what things can affect the count?

[ZerBea]

This is the number of packets that were dropped, due to a lack of buffer space, by the packet capture mechanism in the Linux kernel on
which hcxdumptool/hcxlabtool is running.

hcxdumptool/hcxlabtool captures all raw packets passing through the WiFi interface. The packets have to be parsed and filtered and that takes some time. Running a WiFi interface in monitor mode there are too many incoming packets, and so they are saved to a buffer.

Depending on the traffic on the channel and the performance of your system (CPU cycles) and the rules specified by your command line options (e.g. status display output) that takes some time, so incoming packets have to be buffered (queued) for processing. If they are saved faster than processed, so the buffer runs out of space, and so the kernel drops all further packets until there is some free space in the buffer.

I'll say that everything has a price tag and depending on the features and command line options, you have to pay the price (dropped packets). Running more than one interface or processing additional GPS data or showing a beautiful status display leads you to dropped packets.

At this point we are only talking about the reception branch!
The same applies to the transmission branch too because as an interactive tool, hcxdumptool/hcxlabtool must respond in time to make sure an attack is successful.

BTW:
Depending on the traffic of the current channel, even my RYZEN 8 core is not fast enough to parse all incoming packets and to respond in time too the targets.

[g18z0n]

interesting, if it depends on the hardware specs like cpu cycles, does that mean the system should be at 100% when packets are dropped?

because when i run htop all seems almost idle when hcx is running, be one or more interfaces.

also is there a way to increase that buffer or that would not help at all?, like the “-B” option in tcpdump or any other system/kernel optimization?

overall it seems is normal behavior then.

thanks for the info!

[ZerBea]

Tools of the "top" family like htop, iotop or iftop do not provide an information about the run-time of a single packet inside the interface and inside the kernel.

It is mandatory to understand the "journey of a packet" as explained in this document:
https://www.cs.dartmouth.edu/~sergey/netreads/path-of-packet/Network_stack.pdf

The size of the packet ring buffer is fine. It doesn't make sense to increase it, because the administrative burden is much higher than the benefits. From my point of view, 10% dropped packets are still fine for an interactive tool like hcxdumptool/hcxlabtool. Both tools detect missing packets and request a new one (the value of received packets increase).

The situation is different with a passive dumper (e.g. tshark) because dropped packets are gone for ever.

BTW:
For this reasons (packet traveling inside the kernel), I do not recommend to add a virtual monitor interface and run hcxdumptool/hcxlabtool on it while the phy interface is running in AP-MODE (hostapd).