Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: youghand=codeaurora.org@mg.codeaurora.org
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date:   Thu, 28 Jan 2021 13:38:46 +0530
From:   youghand@codeaurora.org
To:     Felix Fietkau <nbd@nbd.name>
Cc:     johannes@sipsolutions.net, davem@davemloft.net, kuba@kernel.org,
        linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org, kuabhs@chromium.org,
        dianders@chromium.org, briannorris@chromium.org,
        pillair@codeaurora.org
Subject: Re: [PATCH 2/3] mac80211: Add support to trigger sta disconnect on
 hardware restart
In-Reply-To: <f2089f3c-db96-87bc-d678-199b440c05be@nbd.name>
References: <20201215172352.5311-1-youghand@codeaurora.org>
 <f2089f3c-db96-87bc-d678-199b440c05be@nbd.name>
Message-ID: <ba0e6a3b783722c22715ae21953b1036@codeaurora.org>
User-Agent: Roundcube Webmail/1.3.9
Precedence: bulk

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