ok, i think this is correct. I'm bounds checking copy in and copy out of the keys / ioctl buffers; i'm handling 0 byte empty keys properly again so ifconfig and such doesn't error out. I've tested it with CCMP, TKIP and WEP (and I'm sure if CCMP works then GCMP will work, but I'll try to validate that soon.)

change to the new key copy API that returns true/false, not key copy length.

fix; 0 size keys returning 0 == false which leads to APIs returning EINVAL

also it would be nice to count/log the drops here...

This currently throws errors in ifconfig if there's no key (as the key length is 0) - which means it'll error out unless four WEP keys are configured.
I'll need to go and handle the "no key configured, return a blank no key" case before this lands.

another bounds check fix

@bz ok this should implement the behaviours you wanted - bounds checking, buffer zero'ing, etc. Please let me know.

@bz ok this should implement the behaviours you wanted - bounds checking, buffer zero'ing, etc. Please let me know.

update to use the copy out routines

update

update the wep side size check, bz@

another update

oops, missed these

Feedback from bz@

Making this an inline function for the point of making it a function seems hard to justify for single use code.
Can we at least keep it as a normal function in ioctl.c?

Landed via another review (https://reviews.freebsd.org/D49161)

I've been working in this in another stack (https://reviews.freebsd.org/D58384 as an example) to do a lot of needed API cleanup before we can bump this without breaking the current ioctls.

oh damn i missed this, I think it's worth refactoring it so we do have a specific place to pull the TX power from.

Since it is also part of the VHT code path we can't just /not/ do it here; I think we need to handle NULL IE pointers in ieee80211_ht_updateparams_final() and just not do the htinfo deferefence there. (And document that the function must handle NULL IEs.)
Would you like to try that instead?

@adrian It's a (pretty terrible) AP from Huawei

In D58020#1330655, @adrian wrote:

ugh ok why's do_ht being set when there's no htcap/htinfo fields.

OH, hilarious, it's because you have VHT parameters but not HT parameters? That's problematic. Would you mind doing an "ifconfig -v wlan0 list scan" to capture what's being seen in the scan, find the entry that has VHT parameters and not HT parameters, and including it in here?

ugh ok why's do_ht being set when there's no htcap/htinfo fields.

For now I'd like to stay close to the original implementation and only extend the diagnostic where necessary.

In D57762#1327751, @nagymas_gmail.com wrote:

I personally I would go with the simpler solution calling IEEE80211_IS_CHAN_VHTxxx macros already combines mode and width.

static const char *
net80211_get_chanmode_descr(const struct ieee80211_channel *c)
{

...
<VHT*>

I personally I would go with the simpler solution calling IEEE80211_IS_CHAN_VHTxxx macros already combines mode and width.

In D57762#1327568, @adrian wrote:

I think we should just create a function to return a static channel description for this. something like

/*
 * Return a string like <MODE><WIDTH> - eg HT20, VHT80+80, etc.
 */
static const char * net80211_get_chanmode_descr(const struct ieee80211_channel *c)
{
  // do all the HT/VHT stuff currently done in the above log code
 // default
  return "<undef>";
}

What do you think?

I think we should just create a function to return a static channel description for this. something like

Reverted to the original branching to keep the original structure. %s%d changed to %s%s to handle 80P80

Test HT20, HT40, VHT20, VHT40, VHT80, VHT160 not tested VHT80P80

Debug string update to be able to display VHT40U and VHT40D

Original reporting:
VHT80
VHT160
VHT (covers VHT20/VHT40)
Updated reporting:
VHT20
VHT40U
VHT40D
VHT80
VHT160
VHT80P80
Reason:
ni->ni_chan->ic_flags already contains the full channel-width information, so the patch makes the debug output reflect the actual negotiated channel state.

Added every configuration currently available for more accurate debuging

Agreed but we could detail VHT40U and D and VHT20 too

If we do it then let us do better than AI and also document 80P80.