1. 26 9月, 2013 8 次提交
  2. 26 8月, 2013 1 次提交
    • J
      mac80211: fix change_interface queue assignments · a9865538
      Johannes Berg 提交于
      Jouni reported that with mac80211_hwsim, multicast TX was causing
      crashes due to invalid vif->cab_queue assignment. It turns out that
      this is caused by change_interface() getting invoked and not having
      the vif->type/vif->p2p assigned correctly before calling the queue
      check (ieee80211_check_queues). Fix this by passing the 'external'
      interface type to the function and adjusting it accordingly.
      
      While at it, also fix the error path in change_interface, it wasn't
      correctly resetting to the external type but using the internal one
      instead.
      
      Fortunately this affects on hwsim because all other drivers set the
      vif->type/vif->p2p variables when changing iftype. This shouldn't
      be needed, but almost all implementations actually do it for their
      own internal handling.
      Reported-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a9865538
  3. 23 8月, 2013 5 次提交
  4. 22 8月, 2013 1 次提交
  5. 21 8月, 2013 3 次提交
  6. 16 8月, 2013 3 次提交
    • 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
    • S
      mac80211: move ibss presp generation in own function · d51b70ff
      Simon Wunderlich 提交于
      Channel Switch will later require to generate beacons without setting
      them immediately. Therefore split the presp generation in an own
      function. Splitting the original very long function might be a good idea
      anyway.
      Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
      Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d51b70ff
    • J
      mac80211: perform power save processing before decryption · 86c228a7
      Johan Almbladh 提交于
      This patch decouples the power save processing from the frame decryption
      by running the decrypt rx handler after sta_process. In the case where
      the decryption failed for some reason, the stack used to not process
      the PM and MOREDATA bits for that frame. The stack now always performs
      power save processing regardless of the decryption result. That means that
      encrypted data frames and NULLFUNC frames are now handled in the same way
      regarding power save processing, making the stack more robust.
      Signed-off-by: NJohan Almbladh <ja@anyfi.net>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      86c228a7
  7. 13 8月, 2013 1 次提交
  8. 12 8月, 2013 3 次提交
  9. 09 8月, 2013 2 次提交
  10. 06 8月, 2013 1 次提交
  11. 02 8月, 2013 1 次提交
  12. 01 8月, 2013 8 次提交
  13. 23 7月, 2013 1 次提交
  14. 22 7月, 2013 1 次提交
    • C
      mac80211: prevent the buffering or frame transmission to non-assoc mesh STA · 40d18ff9
      Chun-Yeow Yeoh 提交于
      This patch is intended to avoid the buffering to non-assoc mesh STA
      and also to avoid the triggering of frame to non-assoc mesh STA which
      could cause kernel panic in specific hw.
      
      One of the examples, is kernel panic happens to ath9k if user space
      inserts the mesh STA and not proceed with the SAE and AMPE, and later
      the same mesh STA is detected again. The sta_state of the mesh STA remains
      at IEEE80211_STA_NONE and if the ieee80211_sta_ps_deliver_wakeup is called
      and subsequently the ath_tx_aggr_wakeup, the kernel panic due to
      ath_tx_node_init is not called before to initialize the require data
      structures.
      
      This issue is reported by Cedric Voncken before.
      http://www.spinics.net/lists/linux-wireless/msg106342.html
      
      [<831ea6b4>] ath_tx_aggr_wakeup+0x44/0xcc [ath9k]
      [<83084214>] ieee80211_sta_ps_deliver_wakeup+0xb8/0x208 [mac80211]
      [<830b9824>] ieee80211_mps_sta_status_update+0x94/0x108 [mac80211]
      [<83099398>] ieee80211_sta_ps_transition+0xc94/0x34d8 [mac80211]
      [<8022399c>] nf_iterate+0x98/0x104
      [<8309bb60>] ieee80211_sta_ps_transition+0x345c/0x34d8 [mac80211]
      Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      40d18ff9
  15. 16 7月, 2013 1 次提交