> On 4/08/2019, at 11:21 PM, Stefan Sperling <s...@stsp.name> wrote: > On Sun, Aug 04, 2019 at 10:20:24PM +1200, Richard Procter wrote: >> >>> + >>> + return iwm_send_cmd_pdu(sc, IWM_ADD_STA_KEY, IWM_CMD_ASYNC, >>> + sizeof(cmd), &cmd); >> >> Might the async command open a race between loading keys and decrypting >> received packets? > > It can lead to all sorts of races but we have no other option because > net80211 runs lots of code in interrupt context. E.g. we might decide > to switch to a new SSID after a scan, which means we have to delete > the current key and perhaps set a new key. And all this happens in a > context where we're not allowed to sleep. [snip elaboration]
Ah, I see. > Regarding the small window between command initiation and success: > Encryption only affects unicast data frames, and we've already completed > a 4-way handshake with the peer which means newly arriving data frames will > be encrypted. Management frames will still pass. I guess the worst that > might happen is that some data frames sent before the key was installed > might be retransmitted because the firmware would fail to decrypt them. > FWIW, iwn(4) has had the same problem forever and I don't see anyone > complaining. Ok, no objection. btw, I’ve now also tested the fall-back software path against a TKIP AP. best, Richard.
