Search Linux Wireless

Re: [PATCH 2/3] mac80211: Add support to trigger sta disconnect on hardware restart

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux