1. 15 7月, 2022 4 次提交
  2. 20 6月, 2022 13 次提交
  3. 10 6月, 2022 1 次提交
  4. 16 5月, 2022 6 次提交
  5. 05 5月, 2022 1 次提交
  6. 04 5月, 2022 1 次提交
    • M
      mac80211: Reset MBSSID parameters upon connection · 86af062f
      Manikanta Pubbisetty 提交于
      Currently MBSSID parameters in struct ieee80211_bss_conf
      are not reset upon connection. This could be problematic
      with some drivers in a scenario where the device first
      connects to a non-transmit BSS and then connects to a
      transmit BSS of a Multi BSS AP. The MBSSID parameters
      which are set after connecting to a non-transmit BSS will
      not be reset and the same parameters will be passed on to
      the driver during the subsequent connection to a transmit
      BSS of a Multi BSS AP.
      
      For example, firmware running on the ath11k device uses the
      Multi BSS data for tracking the beacon of a non-transmit BSS
      and reports the driver when there is a beacon miss. If we do
      not reset the MBSSID parameters during the subsequent
      connection to a transmit BSS, then the driver would have
      wrong MBSSID data and FW would be looking for an incorrect
      BSSID in the MBSSID beacon of a Multi BSS AP and reports
      beacon loss leading to an unstable connection.
      
      Reset the MBSSID parameters upon every connection to solve this
      problem.
      
      Fixes: 78ac51f8 ("mac80211: support multi-bssid")
      Signed-off-by: NManikanta Pubbisetty <quic_mpubbise@quicinc.com>
      Link: https://lore.kernel.org/r/20220428052744.27040-1-quic_mpubbise@quicinc.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      86af062f
  7. 11 4月, 2022 1 次提交
    • S
      mac80211: prepare sta handling for MLO support · 046d2e7c
      Sriram R 提交于
      Currently in mac80211 each STA object is represented
      using sta_info datastructure with the associated
      STA specific information and drivers access ieee80211_sta
      part of it.
      
      With MLO (Multi Link Operation) support being added
      in 802.11be standard, though the association is logically
      with a single Multi Link capable STA, at the physical level
      communication can happen via different advertised
      links (uniquely identified by Channel, operating class,
      BSSID) and hence the need to handle multiple link
      STA parameters within a composite sta_info object
      called the MLD STA. The different link STA part of
      MLD STA are identified using the link address which can
      be same or different as the MLD STA address and unique
      link id based on the link vif.
      
      To support extension of such a model, the sta_info
      datastructure is modified to hold multiple link STA
      objects with link specific params currently within
      sta_info moved to this new structure. Similarly this is
      done for ieee80211_sta as well which will be accessed
      within mac80211 as well as by drivers, hence trivial
      driver changes are expected to support this.
      
      For current non MLO supported drivers, only one link STA
      is present and link information is accessed via 'deflink'
      member.
      
      For MLO drivers, we still need to define the APIs etc. to
      get the correct link ID and access the correct part of
      the station info.
      
      Currently in mac80211, all link STA info are accessed directly
      via deflink. These will be updated to access via link pointers
      indexed by link id with MLO support patches, with link id
      being 0 for non MLO supported cases.
      
      Except for couple of macro related changes, below spatch takes
      care of updating mac80211 and driver code to access to the
      link STA info via deflink.
      
        @ieee80211_sta@
        struct ieee80211_sta *s;
        struct sta_info *si;
        identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
        @@
      
        (
          s->
        -    var
        +    deflink.var
        |
         si->sta.
        -    var
        +    deflink.var
        )
      
        @sta_info@
        struct sta_info *si;
        identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
        @@
      
        (
          si->
        -    var
        +    deflink.var
        )
      Signed-off-by: NSriram R <quic_srirrama@quicinc.com>
      Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
      [remove MLO-drivers notes from commit message, not clear yet; run spatch]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      046d2e7c
  8. 15 3月, 2022 1 次提交
  9. 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
  10. 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
  11. 16 2月, 2022 3 次提交
  12. 04 2月, 2022 4 次提交
  13. 31 1月, 2022 1 次提交
  14. 04 1月, 2022 2 次提交