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

[bkil]

The CSV can be shaved down a lot by skipping some of the less
interesting variable length fields that grow a lot, like the ones
related to TIM/BA. I aimed to enumerate any and all fields that we
could find any use in, not those fields that are the most interesting.
You can experiment with CSVkit or the simple `cut` to see the effect
of dropping certain columns.

You can also vary snaplen to see the effect on an already made capture
by using `editcap` from wireshark-common. It is perfectly legitime to
cut short any or all frames shorter than their actual lengths. Tools
should handle this, so no need to fill remaining parts with random
bytes.

Now that you've made a nice pcap anonymizer that is easy to extend, it
would be indeed more desirable to share pcap's, especially from a
tooling perspective. I've also considered this possibility and
snaplength might be workable at a basic level, but you have to go
really low. On the card and tcpdump version I tested, the common
minimal radiotap size was 30 bytes, hence 58 bytes of snaplength
ensured that 0 bytes were left from data frames.

You can check this by progressively reducing snaplength and watching
data bytes disappear:
`tshark -x -V -r dump.pcap`

Unfortunately, as radiotap itself is variable length, in case of
transmissions with various properties (like HT vs. non-HT), it can get
bigger, thus snapping into some interesting fields afterwards. Even
with short headers, this snaps in half some mildly interesting frames
like beacons.

It would be best if we had a smart tool to:
* randomize MAC (easiest is hashing with salt or encryption),
* only keep radiotap & wlan headers without data,
* prune a few sensitive parts from wlan as well (authentication, most
beacon IEs, etc.)

I've also been following the thread and waiting for anything to pop up
because you've been experimenting with some very nice things. I
couldn't say for sure, but the IO stat you've shared seems pretty
high, especially if it was only a representative value and not a peak.
Soft-realtime systems are best left idling - reaching 58% utilization
seems like the network could pause pretty often if anything extra
comes in.

Together with the underflows, I would say that at least part of your
problem may not be airtime, but rather CPU time on one or more of your
APs/routers when handling peaks, though again both monitoring and
airtime investigation could give more insight. CPU time recording is
easy (or even forwarding with netcat similar to the pcap examples)

https://github.com/bkil/lede-pcap-investigation/blob/master/wrt-cpu-mon.sh

Recording key fields inside aqm/xmit could also prove to be useful to
correlate with the SmokePing, also a matter of a bit of grep'ping.

Although, if this would be the case, shaping should have provided more
benefits, but we'll have to think about it.

On Tue, Jul 10, 2018 at 2:39 AM, Pete Heist <pete at heistp.net> wrote:
>
>> On Jul 10, 2018, at 1:33 AM, Pete Heist <pete at heistp.net> wrote:
>>
>>> On Jun 30, 2018, at 9:14 PM, bkil <bkil.hu+Aq at gmail.com> wrote:
>>>
>>> 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 set out to write a “simple” pcap anonymizer today in Go and it went smoothly with Ethernet pcaps containing IP data, but if one wants to cover radiotap + 802.11 plus all other protocols where MACs can appear it's not straightforward.
>
> So perhaps I can still find a snaplen that covers radiotap + 802.11 but not any of the data, or I can randomize any leftover data beyond the 802.11 header. I’ll make one more attempt tomorrow. If it works, it might be easier for analysis than the csv.