hiya, 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! -adrian _______________________________________________ freebsd-wireless@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
