update diff url

update diff url

lgtm, whats this addressing? Whats the system behaviour when the count limit is hit?

update diff url

In D44827#1024357, @cc wrote:

In D44827#1023217, @adrian wrote:

In D44827#1023209, @bz wrote:

In D44827#1023208, @adrian wrote:

eg ath(4) would do something like:

How do you want to implement ath_settkipmic() "nicely" without exposing the field?

oops my bad. it'll be a flag for hardware encryption support! I fixed the code snippet.

I don't get it. Without exposing the field ic_cryptocaps? And where is the "fixed the code snippet"?

In D44827#1024561, @bz wrote:

Are you going to change the few drivers which need change to get rid of the public exposure as well? Otherwise this is a dead code before added.

address comments from cc@

update w/ diff url

add missing RSN parsing stuff for hostapd

diff url update

add diff url

diff url

add differential link

comment from emaste

In D44827#1023673, @emaste wrote:

I find it a little confusing with the verb & noun use of set in set_software_cipher_set - do you think set_software_ciphers (or set_sw_ciphers) is reasonable?

oops, url update again

url update

url update

url update

comments from bz

In D44827#1023209, @bz wrote:

In D44827#1023208, @adrian wrote:

eg ath(4) would do something like:

How do you want to implement ath_settkipmic() "nicely" without exposing the field?

eg ath(4) would do something like:

In D44827#1023017, @bz wrote:

Can we shorten hardware/software to hw/sw?

Why do we need wrappers from general code into crypto? Isn't one of them enough to set (and probably also clear[1]) a field in the (currently) ic?

updated after looking at wpa's definition of it in the 802.11 spec headers in it:

rename fields

I'll review the AKM names a second time; stay tuned.

feedback from emaste / bz

add differential revision

• rename software crypto field to better represent what its doing

• rename field / comments to better reflect what's going on
• update commit message to better reflect what's going on

fix commit message

add review

address comments from bz@

Update description

Feedback

you negotiate it as an extension, and then it's used to switch STA keys without dropping frames.

oh, you have a jupiter card with eeprom, rather than just OTP? ooer. Good catch! I likely only have OTP AR9462s :(

looks like it was kip's TOE work from way back when? Maybe there was an out of tree driver / multi-platform driver that used it at some point.

ooo!

Aha i remember now. Ok, so.

In D43634#1007535, @bz wrote:

In D43634#1007529, @adrian wrote:

err, lemme double check this first. SWDECRYPT is not related to hardware encryption offload; it's an earlier thing where you could have RX STA keys in the hardware (to accelerate knowing which STA it belongs to) but it still passes it through untouched requiring one to do encrypt/decrypt in software.

For the ath NICs, the keycache served both as a encryption/decryption key cache and also as a way of marking known STAs in hardware for doing things like auto-ACK, block-ACK tracking, hardware antenna diversity in the older NICs, etc. It doesn't /have/ to contain encryption keys - that's why SWDECRYPT is a thing.

Is IEEE80211_KEY_SWDECRYPT being set somewhere in the linux kpi layer?

I don't think so but that means we need an extra bit of logic. The HW decrypted packets come in and hit ccmp_decrypt() which they definitively shouldn't anymore. So pseudo-code:

if (!IEEE80211_RX_F_DECRYPTED && IEEE80211_KEY_SWDECRYPT) error = xxx_decrypt();  Handle error accrodingly.

Something like this?

err, lemme double check this first. SWDECRYPT is not related to hardware encryption offload; it's an earlier thing where you could have RX STA keys in the hardware (to accelerate knowing which STA it belongs to) but it still passes it through untouched requiring one to do encrypt/decrypt in software.

honestly we should defer rx in net80211, it'd make a whole lot of packet handling w/ state transitions easier

lol well yeah, i think after 10+ years of the software transmit queue handling in ath(4) I can say "ok this shit just works now"

Yeah, thee's no reason not to enable it by default nowdays. :-)

oh wow, howd this get missed :( lemme see if it's still relevant?

nice catch! The iv_bss reference issues strike again! :P

sorry! looks good, I was sick the last couple weeks and missed that. :(