Improving packet sniffing/monitoring on raspberry pi

Question

I have several raspberry pi's that are all the same model with the same build of raspbian and running the same code where I am simply using pyshark to sniff out probe requests and record them to a log file. I can have 5 identical raspberry pi's running the same code sniffing for probe requests in the exact same area and there will be at least a 20% different in the number of probe requests captured for say a 2 hour period. Sometimes higher than a 20% difference. Shouldn't they be much more similar?

I've looked at CPU usage and its not overloading one or multiple cores. THere is plenty of RAM available. The only thing I can think of if over time, raspbian runs various OS related "tuning" and some raspberry pi's have "configured themselves" better than others? (is that possible? Does raspberry pi have system events running that fine tunes itself?)

Here's a sample tshark command that captures my probe requests:

sudo nice -n -15 stdbuf -oL tshark -i wlan1 -I -f 'wlan type mgt subtype probe-req' -Y 'wlan.sa[0:3] ne b8:27:eb && radiotap.dbm_antsignal gt -73' -T fields -e frame.time_epoch -e wlan.sa -e radiotap.dbm_antsignal -E header=y -E separator=, -E quote=d -E occurrence=f >> ../data-test/tsharkoutput.txt

I would expect that if the CPU or RAM isn't tapped out, that different raspberry pi's running the same command should capture pretty close to the same number of packets, but they vary by 20% or more. Any thoughts on why that could be?

Answer 1

Don't use tshark (or libraries that depend on it)

When capturing from a physical interface, tshark is a wrapper for dumpcap. In this mode, tshark experiences higher loss than dumpcap.

You should use dumpcap or tcpdump instead. You will want to use a library other than PyShark if you want to avoid tshark usage.

802.11 traffic is noisy

On a separate note, 802.11 traffic is by definition noisy and prone to loss, so seeing different packets on different capturing devices is expected behavior.