1. 28 4月, 2014 1 次提交
  2. 25 4月, 2014 1 次提交
  3. 09 4月, 2014 4 次提交
  4. 20 2月, 2014 1 次提交
    • J
      mac80211: fix station wakeup powersave race · e3685e03
      Johannes Berg 提交于
      Consider the following (relatively unlikely) scenario:
       1) station goes to sleep while frames are buffered in driver
       2) driver blocks wakeup (until no more frames are buffered)
       3) station wakes up again
       4) driver unblocks wakeup
      
      In this case, the current mac80211 code will do the following:
       1) WLAN_STA_PS_STA set
       2) WLAN_STA_PS_DRIVER set
       3) - nothing -
       4) WLAN_STA_PS_DRIVER cleared
      
      As a result, no frames will be delivered to the client, even
      though it is awake, until it sends another frame to us that
      triggers ieee80211_sta_ps_deliver_wakeup() in sta_ps_end().
      
      Since we now take the PS spinlock, we can fix this while at
      the same time removing the complexity with the pending skb
      queue function. This was broken since my commit 50a9432d
      ("mac80211: fix powersaving clients races") due to removing
      the clearing of WLAN_STA_PS_STA in the RX path.
      
      While at it, fix a cleanup path issue when a station is
      removed while the driver is still blocking its wakeup.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e3685e03
  5. 11 2月, 2014 1 次提交
  6. 06 2月, 2014 1 次提交
  7. 05 2月, 2014 3 次提交
  8. 07 1月, 2014 1 次提交
  9. 19 12月, 2013 2 次提交
    • F
      a7022e65
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
  10. 18 12月, 2013 1 次提交
  11. 16 12月, 2013 1 次提交
  12. 03 12月, 2013 1 次提交
    • J
      nl80211: vendor command support · ad7e718c
      Johannes Berg 提交于
      Add support for vendor-specific commands to nl80211. This is
      intended to be used for really vendor-specific functionality
      that can't be implemented in a generic fashion for any reason.
      It's *NOT* intended to be used for any normal/generic feature
      or any optimisations that could be implemented across drivers.
      
      Currently, only vendor commands (with replies) are supported,
      no dump operations or vendor-specific notifications.
      
      Also add a function wdev_to_ieee80211_vif() to mac80211 which
      is needed for mac80211-based drivers wanting to implement any
      vendor commands.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ad7e718c
  13. 26 11月, 2013 4 次提交
  14. 25 11月, 2013 2 次提交
  15. 28 10月, 2013 4 次提交
    • C
      {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh · c6da674a
      Chun-Yeow Yeoh 提交于
      Allow the triggering of CSA frame using mesh interface. The
      rules are more or less same with IBSS, such as not allowed to
      change between the band and channel width has to be same from
      the previous mode. Also, move the ieee80211_send_action_csa
      to a common space so that it can be re-used by mesh interface.
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c6da674a
    • C
      mac80211: process the CSA frame for mesh accordingly · 8f2535b9
      Chun-Yeow Yeoh 提交于
      Process the CSA frame according to the procedures define in IEEE Std
      802.11-2012 section 10.9.8.4.3 as follow:
      * The mesh channel switch parameters element (MCSP) must be availabe.
      * If the MCSP's TTL is 1, drop the frame but still process the CSA.
      * If the MCSP's precedence value is less than or equal to the current
        precedence value, drop the frame and do not process the CSA.
      * The CSA frame is forwarded after TTL is decremented by 1 and the
        initiator field is set to 0. Transmit restrict field and others
        are maintained as is.
      * No beacon or probe response frame are handled here.
      
      Also, introduce the debug message used for mesh CSA purpose.
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@cozybit.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8f2535b9
    • S
      mac80211: Remove check for offchannel state when waking netdev queues · 17ac4959
      Seth Forshee 提交于
      6c17b77b ensures that a device's
      mac80211 queues will remain stopped while offchannel. Since the
      vif can no longer be offchannel when the queues wake it's not
      necessary to check for this before waking its netdev queues.
      Signed-off-by: NSeth Forshee <seth.forshee@canonical.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17ac4959
    • E
      mac80211: implement SMPS for AP · 687da132
      Emmanuel Grumbach 提交于
      When the driver requests to move to STATIC or DYNAMIC SMPS,
      we send an action frame to each associated station and
      reconfigure the channel context / driver.
      Of course, non-MIMO stations are ignored.
      
      The beacon isn't updated. The association response will
      include the original capabilities. Stations that associate
      while in non-OFF SMPS mode will get an action frame right
      after association to inform them about our current state.
      Note that we wait until the end of the EAPOL. Sending an
      action frame before the EAPOL is finished can be an issue
      for a few clients. Clients aren't likely to send EAPOL
      frames in MIMO anyway.
      
      When the SMPS configuration gets more permissive (e.g.
      STATIC -> OFF), we don't wake up stations that are asleep
      We remember that they don't know about the change and send
      the action frame when they wake up.
      
      When the SMPS configuration gets more restrictive (e.g.
      OFF -> STATIC), we set the TIM bit for every sleeping STA.
      uAPSD stations might send MIMO until they poll the action
      frame, but this is for a short period of time.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [fix vht streams loop, initialisation]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      687da132
  16. 14 10月, 2013 1 次提交
  17. 01 10月, 2013 2 次提交
  18. 27 9月, 2013 1 次提交
  19. 26 9月, 2013 2 次提交
    • S
      mac80211: split off channel switch parsing function · e6b7cde4
      Simon Wunderlich 提交于
      The channel switch parsing function can be re-used for the IBSS code,
      put the common part into an extra function.
      Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
      [also move/rename chandef_downgrade]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e6b7cde4
    • J
      mac80211: add ieee80211_iterate_active_interfaces_rtnl() · c7c71066
      Johannes Berg 提交于
      If it is needed to disconnect multiple virtual interfaces after
      (WoWLAN-) suspend, the most obvious approach would be to iterate
      all interfaces by calling ieee80211_iterate_active_interfaces()
      and then call ieee80211_resume_disconnect() for each one. This
      is what the iwlmvm driver does.
      
      Unfortunately, this causes a locking dependency from mac80211's
      iflist_mtx to the key_mtx. This is problematic as the former is
      intentionally never held while calling any driver operation to
      allow drivers to iterate with their own locks held. The key_mtx
      is held while installing a key into the driver though, so this
      new lock dependency means drivers implementing the logic above
      can no longer hold their own lock while iterating.
      
      To fix this, add a new ieee80211_iterate_active_interfaces_rtnl()
      function that iterates while the RTNL is already held. This is
      true during suspend/resume, so that then the locking dependency
      isn't introduced.
      
      While at it, also refactor the various interface iterators and
      keep only a single implementation called by the various cases.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c7c71066
  20. 16 8月, 2013 1 次提交
    • J
      mac80211: add APIs to allow keeping connections after WoWLAN · 27b3eb9c
      Johannes Berg 提交于
      In order to be able to (securely) keep connections alive after
      the system was suspended for WoWLAN, we need some additional
      APIs. We already have API (ieee80211_gtk_rekey_notify) to tell
      wpa_supplicant about the new replay counter if GTK rekeying
      was done by the device while the host was asleep, but that's
      not sufficient.
      
      If GTK rekeying wasn't done, we need to tell the host about
      sequence counters for the GTK (and PTK regardless of rekeying)
      that was used while asleep, add ieee80211_set_key_rx_seq() for
      that.
      
      If GTK rekeying was done, then we need to be able to disable
      the old keys (with ieee80211_remove_key()) and allocate the
      new GTK key(s) in mac80211 (with ieee80211_gtk_rekey_add()).
      
      If protocol offload (e.g. ARP) is implemented, then also the
      TX sequence counter for the PTK must be updated, using the new
      ieee80211_set_key_tx_seq() function.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      27b3eb9c
  21. 16 7月, 2013 3 次提交
  22. 12 6月, 2013 1 次提交
  23. 05 6月, 2013 1 次提交