1. 15 12月, 2015 1 次提交
  2. 03 12月, 2015 1 次提交
    • J
      mac80211: fix off-channel mgmt-tx uninitialized variable usage · c1df932c
      Johannes Berg 提交于
      In the last change here, I neglected to update the cookie in one code
      path: when a mgmt-tx has no real cookie sent to userspace as it doesn't
      wait for a response, but is off-channel. The original code used the SKB
      pointer as the cookie and always assigned the cookie to the TX SKB in
      ieee80211_start_roc_work(), but my change turned this around and made
      the code rely on a valid cookie being passed in.
      
      Unfortunately, the off-channel no-wait TX path wasn't assigning one at
      all, resulting in an uninitialized stack value being used. This wasn't
      handed back to userspace as a cookie (since in the no-wait case there
      isn't a cookie), but it was tested for non-zero to distinguish between
      mgmt-tx and off-channel.
      
      Fix this by assigning a dummy non-zero cookie unconditionally, and get
      rid of a misleading comment and some dead code while at it. I'll clean
      up the ACK SKB handling separately later.
      
      Fixes: 3b79af97 ("mac80211: stop using pointers as userspace cookies")
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c1df932c
  3. 03 11月, 2015 1 次提交
  4. 15 10月, 2015 3 次提交
  5. 13 10月, 2015 1 次提交
  6. 29 9月, 2015 1 次提交
  7. 22 9月, 2015 4 次提交
  8. 04 9月, 2015 1 次提交
  9. 14 8月, 2015 1 次提交
  10. 17 7月, 2015 5 次提交
  11. 10 6月, 2015 2 次提交
  12. 02 6月, 2015 3 次提交
    • J
      mac80211: stop using pointers as userspace cookies · 3b79af97
      Johannes Berg 提交于
      Even if the pointers are really only accessible to root and used
      pretty much only by wpa_supplicant, this is still not great; even
      for debugging it'd be easier to have something that's easier to
      read and guaranteed to never get reused.
      
      With the recent change to make mac80211 create an ack_skb for the
      mgmt-tx path this becomes possible, only the client probe method
      needs to also allocate an ack_skb, and we can store the cookie in
      that skb.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3b79af97
    • J
      mac80211: copy nl80211 mgmt TX SKB for status · b2eb0ee6
      Johannes Berg 提交于
      When we return the TX status for an nl80211 mgmt TX SKB, we
      should also return the original frame with the status to
      allow userspace to match up the submission (it could also
      use the cookie but both ways are permissible.)
      
      As TX SKBs could be encrypted, at least in the case of ANQP
      while associated with the AP, copy the original SKB, store
      it with an ACK frame ID and restructure the status path to
      use that to return status with the original SKB. Otherwise,
      userspace (in particular wpa_supplicant) will get confused.
      Reported-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b2eb0ee6
    • J
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg 提交于
      For drivers supporting TSO or similar features, but that still have
      PN assignment in software, there's a need to have some memory to
      store the current PN value. As mac80211 already stores this and it's
      somewhat complicated to add a per-driver area to the key struct (due
      to the dynamic sizing thereof) it makes sense to just move the TX PN
      to the keyconf, i.e. the public part of the key struct.
      
      As TKIP is more complicated and we won't able to offload it in this
      way right now (fast-xmit is skipped for TKIP unless the HW does it
      all, and our hardware needs MMIC calculation in software) I've not
      moved that for now - it's possible but requires exposing a lot of
      the internal TKIP state.
      
      As an bonus side effect, we can remove a lot of code by assuming the
      keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.
      
      This might also improve performance, since now TX and RX no longer
      share a cacheline.
      Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      db388a56
  13. 20 5月, 2015 2 次提交
    • J
      mac80211: don't split remain-on-channel for coalescing · 252ec2b3
      Johannes Berg 提交于
      Due to remain-on-channel scheduling delays, when we split an ROC
      while coalescing, we'll usually get a picture like this:
      
      existing ROC:  |------------------|
      current time:              ^
      new ROC:                   |------|              |-------|
      
      If the expected response frames are then transmitted by the peer
      in the hole between the two fragments of the new ROC, we miss
      them and the process (e.g. ANQP query) fails.
      
      mac80211 expects that the window to miss something is small:
      
      existing ROC:  |------------------|
      new ROC:                   |------||-------|
      
      but that's normally not the case.
      
      To avoid this problem, coalesce only if the new ROC's duration
      is <= the remaining time on the existing one:
      
      existing ROC:  |------------------|
      new ROC:                   |-----|
      
      and never split a new one but schedule it afterwards instead:
      
      existing ROC:  |------------------|
      new ROC:                                       |-------------|
      
      type=bugfix
      bug=not-tracked
      fixes=unknown
      Reported-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Reviewed-by: NEliadX Peller <eliad@wizery.com>
      Reviewed-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Tested-by: NMatti Gottlieb <matti.gottlieb@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      252ec2b3
    • M
      mac80211: check fast-xmit on station change · 464daaf0
      Michal Kazior 提交于
      Drivers with fast-xmit (e.g. ath10k) running in
      AP_VLAN setups would fail to communicate with
      connected 4addr stations.
      
      The reason was when new station associates it
      first goes into master AP interface. It is not
      until later that a dedicated AP_VLAN is created
      for it and the station itself is moved there.
      After that Tx directed at the station should use
      4addr header. However fast-xmit wasn't
      recalculated and 3addr header remained to be used.
      This in turn caused the connected 4addr stations
      to drop packets coming from the AP until some
      other event would cause fast-xmit to recalculate
      for that station (which could never come).
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      464daaf0
  14. 06 5月, 2015 2 次提交
  15. 24 4月, 2015 1 次提交
  16. 22 4月, 2015 1 次提交
    • J
      mac80211: add TX fastpath · 17c18bf8
      Johannes Berg 提交于
      In order to speed up mac80211's TX path, add the "fast-xmit" cache
      that will cache the data frame 802.11 header and other data to be
      able to build the frame more quickly. This cache is rebuilt when
      external triggers imply changes, but a lot of the checks done per
      packet today are simplified away to the check for the cache.
      
      There's also a more detailed description in the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17c18bf8
  17. 30 3月, 2015 4 次提交
  18. 20 3月, 2015 1 次提交
  19. 17 3月, 2015 1 次提交
  20. 04 3月, 2015 2 次提交
  21. 01 3月, 2015 1 次提交
  22. 27 1月, 2015 1 次提交