[Make-wifi-fast] mesh deployment with ath9k driver changes

[Pete Heist]

> On Jun 30, 2018, at 9:14 PM, bkil <bkil.hu+Aq at gmail.com> wrote:
> 
> Dear Pete,
> 
> We understand that you are reluctant to share full radiotap wlan
> traces due to privacy reasons and collecting them would strain your
> infrastructure still a bit more.

Thanks for this idea (creative scripts as well!) but I think even the appearance of sharing the packet traces of guests might cause a problem, so I probably won’t be able to.

> Although we can probably give more informed advice based on the
> traces, as a stop gap measure until you finish cabling, you may
> consider traffic shaping of the clients to improve QoS. For example,
> you may put a hard bandwidth cap on each client (or only those coming
> from an AP in question), prioritize HTTP & VoIP traffic and reduce P2P
> traffic, depending on what is the biggest data hog.

I've been playing with that recently actually. I wasn’t able to leave it restricted for long before, but just now I set the per-station limit to 6mbit down / 2mbit up. Some people may not be pleased :), but let’s see what it does for a few days.

One thing I’m surprised by is the amount of data going through the VO queue (view in fixed width font for sanity):

root at Cabin_28:/sys/kernel/debug/ieee80211/phy0/ath9k# cat xmit
                            BE         BK        VI        VO

MPDUs Queued:           218711       5303       435  12846236
MPDUs Completed:      18355992      37807      1672  89811026
MPDUs XRetried:          68553       2409       258   2393713
Aggregates:           28796699     262349      2232         0
AMPDUs Queued HW:            0          0         0         0
AMPDUs Completed:    295460430    2306820    317102         0
AMPDUs Retried:       11666516     120541      3006         0
AMPDUs XRetried:        394366       7493       500         0
TXERR Filtered:         198118       1152        41      1202
FIFO Underrun:              86          0         0      2237
TXOP Exceeded:               0          0         0         0
TXTIMER Expiry:              0          0         0         0
DESC CFG Error:            407          0         0        74
DATA Underrun:               4          0         0         1
DELIM Underrun:            617          0         0        20
TX-Pkts-All:         314279341    2354529    319532  92204739
TX-Bytes-All:        643508167 2628424750 1190327282061782753
HW-put-tx-buf:        94881437    1449351    315153  86013757
HW-tx-start:                 0          0         0         0
HW-tx-proc-desc:      96148496    1449537    314472  92007898
TX-Failed:                   0          0         0         0

And in the aqm driver support I’m not sure what fq_overmemory signifies (Toke may know that) or if the other stats are within the expected ranges for this amount of traffic.

root at Cabin_28:/sys/kernel/debug/ieee80211/phy0# cat aqm
access name value
R fq_flows_cnt 4096
R fq_backlog 0
R fq_overlimit 1716333
R fq_overmemory 58786914
R fq_collisions 4100715
R fq_memory_usage 0
RW fq_memory_limit 4194304
RW fq_limit 8192

> Also, could you by any chance set up monitoring of some addition
> metrics, like CPU usage, I/O wait, load average and memory usage on
> your nodes?

Here’s a snapshot of a gateway AP that’s under typical contentious load in the evening:

Mem: 26908K used, 33628K free, 228K shrd, 356K buff, 4368K cached
CPU:   8% usr  19% sys   0% nic  42% idle   0% io   0% irq  29% sirq
Load average: 0.32 0.20 0.22 1/62 12265

Servicing software interrupts is always a larger portion of the time, which might be expected.

> N.b.: It's a pity that networking trace anonymization tools aren't up
> to the challenge. Simple MAC randomization or hashing with data
> omission would be just fine for such a use case.

I’m also surprised I don’t see an obvious tool to randomize MACs. In the case of releasing captures of guest traffic without asking their permission though, I’m not sure any technical measures would be enough to erase the perception problem, but pseudonymization of all possible identifying values would theoretically satisfy GDPR requirements, for example. After that, it would be extremely difficult (maybe not impossible) without extensive external knowledge to identify users from their traffic.