1. 01 10月, 2011 4 次提交
    • J
      mac80211: split PS buffers into ACs · 948d887d
      Johannes Berg 提交于
      For uAPSD support we'll need to have per-AC PS
      buffers. As this is a major undertaking, split
      the buffers before really adding support for
      uAPSD. This already makes some reference to the
      uapsd_queues variable, but for now that will
      never be non-zero.
      
      Since book-keeping is complicated, also change
      the logic for keeping a maximum of frames only
      and allow 64 frames per AC (up from 128 for a
      station).
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      948d887d
    • J
      mac80211: unify TIM bit handling · c868cb35
      Johannes Berg 提交于
      Currently, the TIM bit for a given station is set
      and cleared all over the place. Since the logic to
      set/clear it will become much more complex when we
      add uAPSD support, as a first step let's collect
      the entire logic in one place. This requires a few
      small adjustments to other places.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c868cb35
    • A
      mac80211: data path modification for TDLS peers · 941c93cd
      Arik Nemtsov 提交于
      Mark the STA entries of enabled TDLS peers with a new "peer authorized"
      flag.
      
      During link setup, allow special TDLS setup frames through the AP, but
      otherwise drop all packets destined to the peer. This is required by the
      TDLS (802.11z) specification in order to prevent reordering of MSDUs
      between the AP and direct paths.
      
      When setup completes and the peer is authorized, send data directly,
      bypassing the AP.
      
      In the Rx path, allow data to be received directly from TDLS peers.
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Cc: Kalyan C Gaddam <chakkal@iit.edu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      941c93cd
    • A
      nl80211/mac80211: allow adding TDLS peers as stations · 07ba55d7
      Arik Nemtsov 提交于
      When adding a TDLS peer STA, mark it with a new flag in both nl80211 and
      mac80211. Before adding a peer, make sure the wiphy supports TDLS and
      our operating mode is appropriate (managed).
      
      In addition, make sure all peers are removed on disassociation.
      
      A TDLS peer is first added just before link setup is initiated. In later
      setup stages we have more info about peer supported rates, capabilities,
      etc. This info is reported via nl80211_set_station().
      Signed-off-by: NArik Nemtsov <arik@wizery.com>
      Cc: Kalyan C Gaddam <chakkal@iit.edu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      07ba55d7
  2. 14 9月, 2011 1 次提交
  3. 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
  4. 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
  5. 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
  6. 17 5月, 2011 3 次提交
  7. 12 5月, 2011 1 次提交
  8. 20 4月, 2011 1 次提交
  9. 13 4月, 2011 1 次提交
  10. 05 4月, 2011 1 次提交
  11. 31 3月, 2011 1 次提交
  12. 02 3月, 2011 1 次提交
  13. 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
  14. 16 12月, 2010 1 次提交
  15. 08 12月, 2010 1 次提交
  16. 30 11月, 2010 1 次提交
  17. 25 11月, 2010 2 次提交
  18. 19 11月, 2010 1 次提交
  19. 07 10月, 2010 2 次提交
  20. 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
  21. 29 6月, 2010 1 次提交
  22. 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
  23. 04 6月, 2010 1 次提交
  24. 25 5月, 2010 1 次提交
  25. 08 4月, 2010 2 次提交
  26. 10 3月, 2010 1 次提交
  27. 11 2月, 2010 1 次提交