VHT80 about authsae

[bcopeland]

Regarding wpa-s and authsae compatibility: there's a set of bugs found this week in how authsae did things compared to what the standard requires, namely:

• mesh should use encryption (group addressed privacy) instead of BIP on the frames. This is a kernel bug for which there is an in-progress patch proposed
• IGTK should be derived separately from the MGTK
• IGTK in peering frames should be optional, only sent if operating PMF network
• peering should be conditional based on whether peer has same PMF requirements as local node
• MFPR/MFPC bits need to be set in RSNE

All of these are going to be fixed in wpa-s so we need to fix those here too. Unfortunately it means a flag day for operating among older versions of authsae and wpa-s. Anyway, I'll open separate issues for these things and make some patches.

[chunyeow]

Go ahead to add this.

[alexgrin]

This commit kind-of/sort-of made VHT80 work for me - uniumwifi@ee5eb27 but I barely tested it.

[bcopeland]

Or use wpa-supplicant which does VHT 80 already :)

[alexgrin]

Yep. The only issue I had with switching to wpa_supplicant was that I couldn't figure out settings that would make nodes running authsae and wpa_supplicant agree on crypto.

[bcopeland]

If so we should fix that -- I know once upon a time I had wpas and authsae nodes talking to each other but I haven't tried in a while. Will give it a bit of testing.

[FredVeldini]

I have used the patch Alexgrin created uniumwifi@ee5eb27 on Authsae previously, it seemed to work fine. Testing with a signal analyzer showed 80MHz working.
You will not be able to add it to the newer code as compiling Errors out.
ampe.h:63:29: error: field 'channel_width' has incomplete type
ampe.h:86:29: error: field 'channel_width' has incomplete type

[alexgrin]

I've refreshed my patch to apply on top of latest authsae and I have two TP-Link Archer C7v2 talking with VHT80.

[bcopeland]

2 years later, merged in 9ef53d4