I've just landed the first part of VHT support. It's enough for me to
continue my ath10k driver port without maintaining thousands of lines
of diffs in sys/net80211/ . Hopefully Andriy and I can continue
chipping away at this whilst we add 11ac support to our drivers over
the next little while.

For everyone else this SHOULD be a glorified no-op. If something
changes then please let me know, preferably via the mailing list.

Next up - there are a few things in net80211 which need addressing as
part of VHT support.

* We need GCMP encryption for 11ac and protected management frames;
i'll talk with andriy a bit more about that and general encryption key
handling so we can figure out how to get that going.

* I'd like to get protected management frames implemented this year in
net80211. THat means peoplec an't just spoof disconnect/reauth/etc
frames at you to disconnect you or get you to reassociate so they can
crack your passphrase.

* Sequence number handling - right now net80211 does it in most cases,
and this is why there's the IEEE8021_TX_LOCK() / IEEE80211_TX_UNLOCK()
around the encap-and-transmit-to-driver path. The drivers need to be
queued frames that are both in the same sequence for allocated
sequence numbers /and/ crypto sequence numbers that get assigned by a
call to iee80211_crypto_encap().

Now, this is the tricky one, because I /think/ I also have to do the
same for mesh sequence number allocation. I'll worry about improving
mesh support later - right now the whole mesh gateway and sequence
number handling is just plain broken.

* Rate control and station notifications need to be addressed. Right
now the only 11n notification is "channel width", which is done on the
whole NIC rather than the node. Ideally it and a bunch of other
notifications (like ERP changes) would be done like mac80211 does it -
per node - with a channel change done if the NIC is software driven
like ath(4).

* Channel configuration - right now it's done globally, which doesn't
really work well for the firmware NICs that can have per-VAP channel
configuration with channel changes driven by the VAP. I'll have a
think about this and maybe do something like mac80211 with it's
per-VAP channel contexts. Ideally drivers would not at all ever check
ic->ic_curchan and net80211 wouldn't set it for firmware NICs -
instead, there'd be a per-VAP channel that's set up whenever things
change, and the firmware would track that per VAP.

* Rate control - right now the rate control API barely does 11n and
needs to grow to do 11ac. I'll talk with Andriy about this a bit more
again to get it more in shape for what the rtwn NICs need for 11ac.
iwm will also need 11ac rate control as it's partially done in the
driver/stack. (ath10k does rate control in firmware, so I have been
able to completely ignore this piece.)

Thanks for testing!

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to