DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 567B220645
MIME-Version: 1.0
References: <a44e3947-29a9-d7ba-abec-59bc1b92b201@candelatech.com>
 <87pnwqaiso.fsf@toke.dk> <CAA93jw768_OOUB1w81_9Ck_XgSbDG4P2nBfuptT+SLXCf3voTA@mail.gmail.com>
 <01b77936-f6d4-271a-d7d2-0fd2cf70f7bd@candelatech.com> <CAA93jw6zjyBeyK2Ln8U4QfgxxES6y7E3opR7YxCpS-khBAea=w@mail.gmail.com>
 <ef20b70a-f885-911a-8e2f-837451974223@candelatech.com>
In-Reply-To: <ef20b70a-f885-911a-8e2f-837451974223@candelatech.com>
From:   Dave Taht <dave.taht@gmail.com>
Date:   Wed, 10 Oct 2018 14:01:35 -0700
Message-ID: <CAA93jw62xzetUVecyO8xS7huZQJvZhu8v9aBjEG1OohftgzkkQ@mail.gmail.com>
Subject: Re: Tool to debug wifi pkt sniffs?
To:     Ben Greear <greearb@candelatech.com>
Cc:     =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@toke.dk>,
        linux-wireless <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

On Wed, Oct 10, 2018 at 1:44 PM Ben Greear <greearb@candelatech.com> wrote:
>
> On 10/10/2018 12:13 PM, Dave Taht wrote:
> > On Wed, Oct 10, 2018 at 10:10 AM Ben Greear <greearb@candelatech.com> w=
rote:
> >>
> >> On 10/03/2018 01:29 PM, Dave Taht wrote:
> >>> On Wed, Oct 3, 2018 at 1:16 PM Toke H=C3=B8iland-J=C3=B8rgensen <toke=
@toke.dk> wrote:
> >>>>
> >>>> Ben Greear <greearb@candelatech.com> writes:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> I often find myself wanting to figure out what equipment is to blam=
e (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 t=
he sniffer's
> >>>>> capture ability, etc.
> >>>>>
> >>>>> Does anyone have anything already written that they would like to s=
hare, or know
> >>>>> of projects that might already do some of this?
> >>>>
> >>>> Not sure if this fits your criteria, but Sven's tool to create airti=
me
> >>>> 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. :)

I did take a quick look at the perl. It's been too long
> >
> > My guess from looking at that output that that was a udp flood test.
> > Do I win the internets?
>
> Yes, UDP upload test with 20 emulated stations, sending ~500 byte UDP fra=
mes.
> One thing we notice in the case we are debugging, is
> that the average time from transmitter station device receiving BA from t=
he AP
> to the transmitter station device putting the next AMPDU frame on air
> is 0.728ms for the problem AP, and 0.448ms for the good AP.

I'm not big on averages. A cdf plot would show you if the delay was consist=
ent
across the range or had a knee in it.

>
> I checked that the wmm config in the beacons for the two APs is the same.
>
> I am at a loss as to what could cause this delay, other than possibly the=
 problem
> AP has a funky transmitter than puts a bit of extra noise on the air afte=
r it
> is done transmitting a frame?

A possible explanation would be garbage at one or more tried mcs rate
(not successfully captured).
minstrel at least tries multiple mcs rates.

>
> The problem AP also has 5% retransmits vs about 2% for the good AP, and p=
roblem AP
> is typically using MCS8 instead of MCS9, but even so, I do not see how th=
at would explain
> the extra BA to AMPDU delay.

It's highly probable I'm misunderstanding you and would need to look
directly at the cap.

"typically using" says to me "more often trying the wrong rate"

>
> Thanks,
> Ben
>
>
> --
> Ben Greear <greearb@candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>


--=20

Dave T=C3=A4ht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740