On Wed, Oct 10, 2018 at 10:10 AM Ben Greear <[email protected]> wrote: > > On 10/03/2018 01:29 PM, Dave Taht wrote: > > On Wed, Oct 3, 2018 at 1:16 PM Toke Høiland-Jørgensen <[email protected]> wrote: > >> > >> Ben Greear <[email protected]> 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: > > https://github.com/greearb/lanforge-scripts > > 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: > > https://www.candelatech.com/oss/wifi-diag/netgear-up-5s/index.html
I *miss* writing in perl. :) My guess from looking at that output that that was a udp flood test. Do I win the internets? > > 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? > > > Thanks, > Ben > > -- > Ben Greear <[email protected]> > Candela Technologies Inc http://www.candelatech.com > -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740
