1. 01 7月, 2022 3 次提交
  2. 20 6月, 2022 16 次提交
  3. 10 6月, 2022 1 次提交
  4. 16 5月, 2022 2 次提交
  5. 05 5月, 2022 1 次提交
  6. 15 3月, 2022 1 次提交
  7. 11 3月, 2022 1 次提交
    • Y
      mac80211: Add support to trigger sta disconnect on hardware restart · 7d352ccf
      Youghandhar Chintala 提交于
      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, 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.
      
      Tested on ath10k using WCN3990, QCA6174
      Signed-off-by: NYoughandhar Chintala <youghand@codeaurora.org>
      Link: https://lore.kernel.org/r/20220308115325.5246-2-youghand@codeaurora.orgSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      7d352ccf
  8. 01 3月, 2022 1 次提交
    • J
      mac80211: treat some SAE auth steps as final · 94d9864c
      Johannes Berg 提交于
      When we get anti-clogging token required (added by the commit
      mentioned below), or the other status codes added by the later
      commit 4e56cde1 ("mac80211: Handle special status codes in
      SAE commit") we currently just pretend (towards the internal
      state machine of authentication) that we didn't receive anything.
      
      This has the undesirable consequence of retransmitting the prior
      frame, which is not expected, because the timer is still armed.
      
      If we just disarm the timer at that point, it would result in
      the undesirable side effect of being in this state indefinitely
      if userspace crashes, or so.
      
      So to fix this, reset the timer and set a new auth_data->waiting
      in order to have no more retransmissions, but to have the data
      destroyed when the timer actually fires, which will only happen
      if userspace didn't continue (i.e. crashed or abandoned it.)
      
      Fixes: a4055e74 ("mac80211: Don't destroy auth data in case of anti-clogging")
      Reported-by: NJouni Malinen <j@w1.fi>
      Link: https://lore.kernel.org/r/20220224103932.75964e1d7932.Ia487f91556f29daae734bf61f8181404642e1eec@changeidSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      94d9864c
  9. 16 2月, 2022 4 次提交
  10. 04 2月, 2022 1 次提交
  11. 04 1月, 2022 1 次提交
  12. 26 11月, 2021 1 次提交
  13. 21 10月, 2021 1 次提交
  14. 23 9月, 2021 4 次提交
  15. 26 8月, 2021 1 次提交
  16. 24 8月, 2021 1 次提交