Since using DELBA frame to APs to re-establish BA session has a dependency on APs and also some APs may not honour the DELBA frame. I am fine with having the disconnect/reconnect solution. The change looks good to me. Reviewed-by: Abhishek Kumar <kuabhs@xxxxxxxxxxxx> Thanks Abhishek On Thu, Jan 28, 2021 at 12:08 AM <youghand@xxxxxxxxxxxxxx> wrote: > > On 2020-12-15 23:10, Felix Fietkau wrote: > > On 2020-12-15 18:23, Youghandhar Chintala wrote: > >> Currently in case of target hardware restart, we just reconfig and > >> re-enable the security keys and enable the network queues to start > >> data traffic back from where it was interrupted. > >> > >> Many ath10k wifi chipsets have sequence numbers for the data > >> packets assigned by firmware and the mac sequence number will > >> restart from zero after target hardware restart leading to mismatch > >> in the sequence number expected by the remote peer vs the sequence > >> number of the frame sent by the target firmware. > >> > >> This mismatch in sequence number will cause out-of-order packets > >> on the remote peer and all the frames sent by the device are dropped > >> until we reach the sequence number which was sent before we restarted > >> the target hardware > >> > >> In order to fix this, we trigger a sta disconnect, for the targets > >> which expose this corresponding wiphy flag, in case of target hw > >> restart. After this there will be a fresh connection and thereby > >> avoiding the dropping of frames by remote peer. > >> > >> The right fix would be to pull the entire data path into the host > >> which is not feasible or would need lots of complex changes and > >> will still be inefficient. > > How about simply tracking which tids have aggregation enabled and send > > DELBA frames for those after the restart? > > It would mean less disruption for affected stations and less ugly hacks > > in the stack for unreliable hardware. > > > > - Felix > > Hi Felix, > > We did try to send an ADDBA frame to the AP once the SSR happened. The > AP ack’ed the frame and the new BA session with renewed sequence number > was established. But still, the AP did not respond to the ping requests > with the new sequence number. It did not respond until one of the two > happened. > 1. The sequence number was more than the sequence number that DUT had > used before SSR happened > 2. DUT disconnected and then reconnected. > The other option is to send a DELBA frame to the AP and make the AP also > force to establish the BA session from its side. This we feel can have > some interoperability issues as some of the AP’s may not honour the > DELBA frame and will continue to use the earlier BA session that it had > established. Given that re-negotiating the BA session is prone to IOT > issues, we feel that it would be good to go with the > Disconnect/Reconnect solution which is foolproof and will work in all > scenarios. > > Regards, > Youghandhar
