[Make-wifi-fast] Fwd: Tool to debug wifi pkt sniffs?

Dave Taht dave.taht at gmail.com
Wed Oct 10 13:21:01 EDT 2018

---------- Forwarded message ---------
From: Ben Greear <greearb at candelatech.com>
Date: Wed, Oct 10, 2018 at 10:10 AM
Subject: Re: Tool to debug wifi pkt sniffs?
To: Dave Taht <dave.taht at gmail.com>, Toke Høiland-Jørgensen <toke at toke.dk>
Cc: linux-wireless <linux-wireless at vger.kernel.org>

On 10/03/2018 01:29 PM, Dave Taht wrote:
> On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-Jørgensen <toke at toke.dk> wrote:
>> Ben Greear <greearb at candelatech.com> writes:
>>> Hello,
>>> I often find myself wanting to figure out what equipment is to blame (and why)
>>> in a wifi environment.
>>> I am thinking writing a tool that would parse a pcap file and look at frames
>>> in enough detail to flag block-ack bugs, rate-ctrl bugs, guess at the sniffer's
>>> capture ability, etc.
>>> Does anyone have anything already written that they would like to share, or know
>>> of projects that might already do some of this?
>> Not sure if this fits your criteria, but Sven's tool to create airtime
>> charts from packet sniffing data immediately came to mind:
>> https://github.com/cloudtrax/airtime-pie-chart
> I have used that. Oy, it's a PITA. Some of kathie's code over here
> (example: https://github.com/pollere/pping ) uses the slightly less
> painful http://libtins.github.io/ library for parsing packets.

I couldn't find anything that did what I wanted, so I wrote my own.

The (perl) code is in the wifi-diag directory of this public repo:


The rest of the scripts in that repo are not related to the wifi-diag
script, so just ignore those.

Here is example output for what I have so far:


The general idea is to get a performance test going, and then use
tshark or similar
to grab a short sample (my script is slow, it can process only about
400 packets per second
on my desktop, so a 5 sec capture at full speed takes around 5 minutes
to process),
and then pipe that decoded pcap into my script.

It tries to pay attention to latencies between block-ack and next AMPDU frame,
MCS distributions, packet-type distributions, retries, and other
such things.  I'm guessing tweaking wmm settings (or changing QoS in
the generated traffic)
would be visible in this kind of metric, for instance.

The goal is to be able to answer the question of why one AP is faster
or slower than another
when running the same test case.

Feedback (and even patches) is welcome...what other things can I
report that would
be helpful?


Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


Dave Täht
CTO, TekLibre, LLC
Tel: 1-831-205-9740

More information about the Make-wifi-fast mailing list