net80211: clean up / add more macros to check the frame types

[adrian]

Summary

• Add new macros to check the version, version+type and version+type+subtype of a frame.
• Use these for existing frame type checks
• Add new frame type checks
• Convert the use of these flag checks to use the macros, not direct header poking.

Notably I'm calling out things like QOS any versus QOS data, the
kind of NULL frames, etc. Eg, in the TKIP code it's checking whether
a frame is ANY kind of QOS frame, not just QOS data.

These macros should hopefully make the header checks clearer and less
error prone. They're also useful in drivers that are doing their own
header parsing.

Locally:

• ath(4) - AP, STA, AP+STA modes
• local ath10k/athp - AP, STA modes

[bz]

I'll review next week when back in the office.

[bz]

sys/net80211/ieee80211.h

210

"ext" missing in the comment.

224

I like the above. I was talking about WiFi version checks with someone the other day :)

227

This will need a de-dup with a few drivers. Are you planning on doing that?

233

I don't see this possibly used anywhere in our current code base. Do you need it?

251

All three are unused and we seem to do checks on the subtype in switch/case statements. Do you need them anywhere at all?

I see on possible use case for IS_ACTION_ACK() and that is called "IS_ACTION" everywhere else (incl. the case in ath). I'll find this confusing.
I don't see any use cases for the latter two. If you need any, please specify?

261

Unused? We seem to use IEEE80211_FC0_SUBTYPE_DISASSOC basically in switch/case statements for checks. Do you plan to use it as well? Do we need this?

271

If this is now no longer needed we should remove it.

275

/* This returns true if it is any QOS frame. */

shorter, less confusing, and fits in a single line; but then this is what the macro name indicates and makes one wonder if the comment is needed at all?

283

No "/" markup in comments. "only" already emphasize the point.
Also below.

298

This is unused? Do we then need it or are we just adding it for the sake of having more stuff at this point?

sys/net80211/ieee80211_crypto_tkip.c

865

superfluous comment (that's what the macro is) and we don't do random markup in kernel comments usually.

sys/net80211/ieee80211_proto.h

332

Where do you need that? I don't like adding unused inline unctions for the sake of being there.
And even if we'd either need to comment the hard coded values or use offsetof so make it clear.

[adrian]

They're all used in the ath10k driver port I'm working on. They're available in the linuxkpi for liinux drivers too :-)

[adrian]

sys/net80211/ieee80211.h

271

i'll go sweep the drivers and see what else can be done to remove this. I didn't want to break the rest of the system in the first pass.

[adrian]

sys/net80211/ieee80211_proto.h

332

it's actually exposed in mac80211, and it's used by my net80211 driver. there's a bunch of qos frame encap/decap being done in the driver because of what the hardware/firmware is doing to frames.

(The TL;DR is the microsoft wifi format was non-QoS, so to natively support microsoft Wifi frame formats, the hardware would decap the QoS section for you and then stuff the contents in the receive descriptor so you could re-build it for the stack.)

[adrian]

sys/net80211/ieee80211.h

271

hi! one driver uses this, so guess I'll turn this into a bit of a commit stack. stay tuned.

[bz]

sys/net80211/ieee80211.h

271

Must be out-of-tree as a grep -r through the entire tree only showed net80211. I'll stay tuned.

sys/net80211/ieee80211_proto.h

332

The only thing I am aware is ieee80211_get_qos_ctl() and that does return the pointer not the offset very much like we do for ieee80211_getqos() or ieee80211_gettid() in net80211.

[adrian]

sys/net80211/ieee80211.h

271

It's included in the iwl linux driver from the linux include stuff. Guess you're currently using it in the compat code?

sys/net80211/ieee80211_proto.h

332

Lemme see; this i can do away with for now cause it's only used by the ath10k port that's not yet landed.