1. 26 8月, 2011 1 次提交
    • G
      mac80211: fix race condition between assoc_done and first EAP packet · 2a33bee2
      Guy Eilam 提交于
      When associating to an AP, the station might miss the first EAP
      packet that the AP sends due to a race condition between the association
      success procedure and the rx flow in mac80211.
      In such cases, the packet might fall in ieee80211_rx_h_check due to
      the fact that the relevant rx->sta wasn't allocated yet.
      Allocation of the relevant station info struct before actually
      sending the association request and setting it with a new
      dummy_sta flag solve this problem.
      The station will accept only EAP packets from the AP while it
      is in the pre-association/dummy state.
      This dummy station entry is not seen by normal sta_info_get()
      calls, only by sta_info_get_bss_rx().
      The driver is not notified for the first insertion of the
      dummy station. The driver is notified only after the association
      is complete and the dummy flag is removed from the station entry.
      That way, all the rest of the code flow should be untouched by
      this change.
      Signed-off-by: NGuy Eilam <guy@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a33bee2
  2. 08 7月, 2011 1 次提交
    • J
      mac80211: simplify RX PN/IV handling · 9e26297a
      Johannes Berg 提交于
      The current rx->queue value is slightly confusing.
      It is set to 16 on non-QoS frames, including data,
      and then used for sequence number and PN/IV checks.
      Until recently, we had a TKIP IV checking bug that
      had been introduced in 2008 to fix a seqno issue.
      Before that, we always used TID 0 for checking the
      PN or IV on non-QoS packets.
      
      Go back to the old status for PN/IV checks using
      the TID 0 counter for non-QoS by splitting up the
      rx->queue value into "seqno_idx" and "security_idx"
      in order to avoid confusion in the future. They
      each have special rules on the value used for non-
      QoS data frames.
      
      Since the handling is now unified, also revert the
      special TKIP handling from my patch
      "mac80211: fix TKIP replay vulnerability".
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9e26297a
  3. 08 6月, 2011 1 次提交
    • S
      mac80211: Stop BA session event from device · f41ccd71
      Shahar Levi 提交于
      Some devices support BT/WLAN co-existence algorigthms.
      In order not to harm the system performance and user experience, the device
      requests not to allow any RX BA session and tear down existing RX BA sessions
      based on system constraints such as periodic BT activity that needs to limit
      WLAN activity (eg.SCO or A2DP).
      In such cases, the intention is to limit the duration of the RX PPDU and
      therefore prevent the peer device to use A-MPDU aggregation.
      
      Adding ieee80211_stop_rx_ba_session() callback
      that can be used by the driver to stop existing BA sessions.
      Signed-off-by: NShahar Levi <shahar_levi@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f41ccd71
  4. 17 5月, 2011 3 次提交
  5. 12 5月, 2011 1 次提交
  6. 20 4月, 2011 1 次提交
  7. 13 4月, 2011 1 次提交
  8. 05 4月, 2011 1 次提交
  9. 31 3月, 2011 1 次提交
  10. 02 3月, 2011 1 次提交
  11. 20 1月, 2011 1 次提交
    • J
      mac80211: track receiver's aggregation reorder buffer size · 0b01f030
      Johannes Berg 提交于
      The aggregation code currently doesn't implement the
      buffer size negotiation. It will always request a max
      buffer size (which is fine, if a little pointless, as
      the mac80211 code doesn't know and might just use 0
      instead), but if the peer requests a smaller size it
      isn't possible to honour this request.
      
      In order to fix this, look at the buffer size in the
      addBA response frame, keep track of it and pass it to
      the driver in the ampdu_action callback when called
      with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
      way the driver can limit the number of subframes in
      aggregates appropriately.
      
      Note that this doesn't fix any drivers apart from the
      addition of the new argument -- they all need to be
      updated separately to use this variable!
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0b01f030
  12. 16 12月, 2010 1 次提交
  13. 08 12月, 2010 1 次提交
  14. 30 11月, 2010 1 次提交
  15. 25 11月, 2010 2 次提交
  16. 19 11月, 2010 1 次提交
  17. 07 10月, 2010 2 次提交
  18. 17 8月, 2010 1 次提交
    • C
      mac80211: AMPDU rx reorder timeout timer · 2bff8ebf
      Christian Lamparter 提交于
      This patch introduces a new timer, which will release
      queued-up MPDUs from the reorder buffer, whenever
      they've waited for more than HT_RX_REORDER_BUF_TIMEOUT
      (which is at around 100 ms).
      
      The advantage of having a dedicated timer, instead of
      relying on a constant stream of freshly arriving aMPDUs
      to release the old ones, is particularly observable when
      even a small fraction of MPDUs are forever lost at
      low network speeds.
      
      Previously under these circumstances frames would become
      stuck in the reorder buffer and the network stack of both
      HT peers throttled back, instead of revving up and
      gunning the pipes.
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2bff8ebf
  19. 29 6月, 2010 1 次提交
  20. 15 6月, 2010 6 次提交
    • J
      mac80211: change RX aggregation locking · a93e3644
      Johannes Berg 提交于
      To prepare for allowing drivers to sleep in
      ampdu_action, change the locking in the RX
      aggregation code to use a mutex, so that it
      would already allow drivers to sleep. But
      explicitly disable BHs around the callback
      for now since the TX part cannot yet sleep,
      and drivers' locking might require it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a93e3644
    • J
      mac80211: defer RX agg session teardown to work · 7c3b1dd8
      Johannes Berg 提交于
      Since we want the code to be able to sleep
      in the future, it must not be called from
      the timer directly. To prepare, move it out
      into the aggregation work.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7c3b1dd8
    • J
      mac80211: make TX aggregation start/stop request async · 0ab33703
      Johannes Berg 提交于
      When the driver or rate control requests starting
      or stopping an aggregation session, that currently
      causes a direct callback into the driver, which
      could potentially cause locking problems. Also,
      the functions need to be callable from contexts
      that cannot sleep, and thus will interfere with
      making the ampdu_action callback sleeping.
      
      To address these issues, add a new work item for
      each station that will process any start or stop
      requests out of line.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0ab33703
    • J
      mac80211: use RCU for TX aggregation · a622ab72
      Johannes Berg 提交于
      Currently we allocate some memory for each TX
      aggregation session and additionally keep a
      state bitmap indicating the state it is in.
      By using RCU to protect the pointer, moving
      the state into the structure and some locking
      trickery we can avoid locking when the TX agg
      session is fully operational.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a622ab72
    • J
      mac80211: use RCU for RX aggregation · a87f736d
      Johannes Berg 提交于
      Currently we allocate some memory for each RX
      aggregation session and additionally keep a
      flag indicating whether or not it is valid.
      By using RCU to protect the pointer and making
      sure that the memory is fully set up before it
      becomes visible to the RX path, we can remove
      the need for the bool that indicates validity,
      as well as for locking on the RX path since it
      is always synchronised against itself, and we
      can guarantee that all other modifications are
      done when the structure is not visible to the
      RX path.
      
      The net result is that since we remove locking
      requirements from the RX path, we can in the
      future use any kind of lock for the setup and
      teardown code paths.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a87f736d
    • J
      mac80211: simplify station/aggregation code · 2a419056
      Johannes Berg 提交于
      A number of places use RCU locking for accessing
      the station list, even though they do not need
      to. Use mutex locking instead to prepare for the
      locking changes I want to make. The mlme code is
      also using a WLAN_STA_DISASSOC flag that has the
      same meaning as WLAN_STA_BLOCK_BA, so use that.
      
      While doing so, combine places where we loop
      over stations twice, and optimise away some of
      the loops by checking if the hardware supports
      aggregation at all first.
      
      Also fix a more theoretical race condition: right
      now we could resume, set up an aggregation session,
      and right after tear it down again due to the code
      that is needed for hardware reconfiguration here.
      Also mark add a comment to that code marking it as
      a workaround.
      
      Finally, remove a pointless aggregation disabling
      loop when an interface is stopped, directly after
      that we remove all stations from it which will also
      disable all aggregation sessions that may still be
      active, and does so in a race-free way unlike the
      current loop that doesn't block new sessions.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2a419056
  21. 04 6月, 2010 1 次提交
  22. 25 5月, 2010 1 次提交
  23. 08 4月, 2010 2 次提交
  24. 10 3月, 2010 1 次提交
  25. 11 2月, 2010 1 次提交
  26. 09 2月, 2010 1 次提交
    • J
      mac80211: allow station add/remove to sleep · 34e89507
      Johannes Berg 提交于
      Many drivers would like to sleep during station
      addition and removal, and currently have a high
      complexity there from not being able to.
      
      This introduces two new callbacks sta_add() and
      sta_remove() that drivers can implement instead
      of using sta_notify() and that can sleep, and
      the new sta_add() callback is also allowed to
      fail.
      
      The reason we didn't do this previously is that
      the IBSS code wants to insert stations from the
      RX path, which is a tasklet, so cannot sleep.
      This patch will keep the station allocation in
      that path, but moves adding the station to the
      driver out of line. Since the addition can now
      fail, we can have IBSS peer structs the driver
      rejected -- in that case we still talk to the
      station but never tell the driver about it in
      the control.sta pointer. If there will ever be
      a driver that has a low limit on the number of
      stations and that cannot talk to any stations
      that are not known to it, we need to do come up
      with a new strategy of handling larger IBSSs,
      maybe quicker expiry or rejecting peers.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34e89507
  27. 13 1月, 2010 1 次提交
  28. 22 12月, 2009 1 次提交
    • J
      mac80211: make station management completely depend on vif · abe60632
      Johannes Berg 提交于
      The station management currently uses the virtual
      interface, but you cannot add the same station to
      multiple virtual interfaces if you're communicating
      with it in multiple ways.
      
      This restriction should be lifted so that in the
      future we can, for instance, support bluetooth 3
      with an access point that mac80211 is already
      associated to.
      
      We can do that by requiring all sta_info_get users
      to provide the virtual interface and making the RX
      code aware that an address may match more than one
      station struct. Thanks to the previous patches this
      one isn't all that large and except for the RX and
      TX status paths changes has low complexity.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      abe60632
  29. 24 11月, 2009 1 次提交
  30. 19 11月, 2009 1 次提交