On Fri, Sep 24, 2021 at 11:20:50AM +0200, Johannes Berg wrote: > > We thought sending the delba would solve the problem as earlier thought > > but the actual problem is with TX PN in a secure mode. > > It is not because of delba that the Seq number and TX PN are reset to > > zero. > > It’s because of the HW restart, these parameters are reset to zero. > > Since FW/HW is the one which decides the TX PN, when it goes through > > SSR, all these parameters are reset. > > Right, we solved this problem too - in a sense the driver reads the > database (not just TX PN btw, also RX replay counters) when the firmware > crashes, and sending it back after the restart. mac80211 has some hooks > for that. This might be doable for some cases where the firmware is the component assigning the PN values on TX and the firmware still being in a state where the counter used for this could be fetched after a crash or detected misbehavior. However, this does not sound like a very reliable mechanism for cases where the firmware state for this cannot be trusted or for the cases where the TX PN is actually assigned by the hardware (which would get cleared on that restart and the value might be unreadable before that restart). Trying to pull for this information periodically before the issue is detected does not sound like a very robust design either, since that would both waste resources and have a race condition with the lower layers having transmitted additional frames. Obviously it would be nice to be able to restore this type of state in all cases accurately, but that may not really be a viable approach for all designs and it would seem to make sense to provide an alternative approach to minimize the user visible impact from the rare cases of having to restart some low level components during an association. -- Jouni Malinen PGP id EFC895FA
