On 24 October 2016 at 11:55, Andriy Voskoboinyk <a...@freebsd.org> wrote: > Mon, 24 Oct 2016 19:36:08 +0300 було написано Adrian Chadd > <adr...@freebsd.org>: > > Hi! > >> hiya, >> >> So I have my ath10k driver port up and running in 11abg (not n/ac) >> mode. The hardware is .. highly offload-y. There are three/four data >> pipelines - "raw" mode, "native wifi" mode, "ethernet" mode, and >> "management TX/RX" mode. >> >> * "raw" mode is raw, untouched 802.11 frames. This is the most >> flexible but it means we have to do software encryption and A-MSDU >> encap/decap. >> * "native wifi" mode is microsoft 802.11 framing. This is like 802.11, >> but there's no QoS field. Yes, the QoS field is in the descriptor >> field and the hardware will add/delete it for you. >> * "ethernet" mode is 802.3 encap/decap ethernet. >> * "management" mode is a separate TX/RX pipeline for management frames >> (eg beacons, probe requests, etc.) The firmware is the normal target >> for management frames and it takes care of sending up frames that the >> stack needs to see. >> >> Now, this makes crypto a bit of a pain to implement. Notably: >> >> * There's no hardware key index that we see. It's all done per-peer. >> So, each peer has the 0..4 wep key slot, then I think 0..4 for >> pairwise keys (even though we only support keyidx 0 for now) with >> flags to say "current TX key (for WEP), "pairwise", "group" keys. >> * The group key is per-peer - so no, you don't program it in with an >> address of ff:ff:ff:ff:ff:ff. It needs to be the BSS MAC. > > > > That's similar to wpi(4) / iwn(4) crypto: > - they has some special 'set global WEP keys 0..3' firmware command; > - every node (24 for wpi(4), 16 (?) for iwn(4) has its own Rx key table > (8 pairwise + 8 group). > - encryption key is set in Tx descriptor. > (BTW, that's already implemented in wpi(4) (AES-CCM only))
Ok, so good - this work can be used by the other NICs in a mostly immediate fashion. >> * For raw mode, you don't need any keys, just send frames. >> * For native wifi (and I'm guessing ethernet) you have to add a CLEAR >> GTK/PMK key to a peer before it'll start transmitting traffic to said >> peer - the firmware buffers frames until the four-way handshake is >> done. >> * For QoS traffic the hardware/firmware seems to corrupt software >> encryption. Which, if you think about it, makes sense - the hardware >> has to insert the QoS header into the frame and then transmit it, >> which means if it makes /any/ change to make the packet contents not >> line up, it won't decrypt right. >> >> The mac80211/ath10k paths do software encryption/decryption for GCMP, >> which we currently don't support. So there /is/ some way to do >> completely software encryption/decryption, as long as it's non-QoS >> management frame style traffic. >> >> So those are the annoying bits. The net80211 bits that need to change are: >> >> * The encryption hardware doesn't want an IV, FCS or MIC - it instead >> will add the IV, MIC and WEP FCS itself. So during encap we shouldn't >> provide it. >> * .. and for management traffic, it depends. Sometimes it does, >> sometimes it doesn't. >> * For decryption, the hardware will fully decrypt the frame, including >> stripping IV/MIC/WEPFCS. It instead passes up flags in the descriptor >> to say "decrypted ok", "MIC failed", "CRC/FCS failed", etc. So a lot >> of the decap path can't run - there's no IV to get a keyindex from, >> and there's no MIC to check against / strip. > > > > run(4) does something similar - it does not call ieee80211_crypto_encap() > for Tx and checks Rx descriptor flags before passing the frame to net80211 Ok. So we should fix this in the TX encap path in net80211 first, then make sure we call crypto_encap in run. The reason? So when we grow say, GCMP (for management frame protection) we can do hybrid software/hardware crypto schemes. -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"
