update w/ url

In D46683#1067664, @kp wrote:

In D46683#1067412, @glebius wrote:

I see no good reason to ifdef pieces of enum. Makes sense to disable some code for NOINET or NOINET6 kernels, but what's the point in disabling a piece of declaration?

If we don't we upset the compiler in LINT-NOINET (and LINT-NOINET6) kernels:

/usr/src/sys/netpfil/pf/pf_lb.c:769:13: error: enumeration value 'IP_AF_4' not handled in switch [-Werror,-Wswitch]
  769 |                                 switch (pd->af) {
      |                                         ^~~~~~

It's fairly common to have code specific to one address family or another not be compiled in those kernels, so we end up with switch statements that don't handle all options. We can prevent this by adding a default: panic("Unknown af %d", af) case, but removing that was the reason to go down this path in the first place.

What's the desired behaviour of this code though if you don't define inet and inet6? Why would you even build pf at that point?

Lemme finish getting some more changes cleaned up and landed first. I have the MFP ioctl stuff to get into the wpa driver and GCMP to land in net80211 - enough so people can at least use it and make sure it isn't broken.

add differential URL

update URL

add url

update url

add url

add URL

oh crap, we should change ah_diversity to be the right type. HAL_ANT_VARIABLE is different!

can you add a comment above each macro just saying that != 0 is a check that it's HAL_FREQ_BAND_2GHZ? other than that, go ahead!

oops, missed indenting!

URL update

add URL

Update URL

Add URL

update url

feedback from bz:

update

oops, fix compile

update url

more updates

address comments from bz@

add url

Note - I'm landing this as a standalone diff for review, but it hasn't yet had any thorough testing. Stay tuned.

add differential url

rename field, from cc@

The comlock is also a problem. But we shouldn't need to hold the lock whilst we do things like transmit; we're only required to do that because of how the state changes happen. The early net80211 drivers had almost no locking outside of ieee80211com. I've seen what vendors have done to net80211 to "fix locking" by changing the lock types, making some sleepable, etc ... it's just terrible.

Ah, crap. This stuff. Yeah, I hit this in ath(4) and iwn(4) way back when. It's a pain in the butt. I even think ath(4) has a workaround to drop frames in this instance because of exactly what you found.

whoops! nice catch.

Yeah, I remember hitting namespace clashes when trying to do this with some earlier linux driver ports. :(

add the modules Makefile

The real problem isn't the ABI key size, it's that the current net80211 API routine expects the ioctl size is fixed. If that size check wasn't there and we relied on the key request key size and verified it fit inside the ioctl buffer size then we'd be fine.

In D44920#1026551, @emaste wrote:

Can we decouple userland use in ifconfig? i.e., have ifconfig support 384 bits now

I'm sure I've seen FCSes in 802.11 bpf traces? Maybe that's happening at the 802.11 radiotap level?

oh, interesting! does 11n work on this driver in openbsd? I see some 11n stuff is commented out here.

remove the VAP keymgmt flags for now; will reintroduce it and change the
ioctl API to use that instead when it's necessary.

remove NONE, from bz@