1. 27 Mar, 2009 2 commits
  2. 16 Mar, 2009 4 commits
    • Herton Ronaldo Krzesinski's avatar
      mac80211: deauth before flushing STA information · 1a28c78b
      Herton Ronaldo Krzesinski authored
      Even after commit "mac80211: deauth when interface is marked down"
      (e327b847 on Linus tree), userspace still isn't notified when interface
      goes down. There isn't a problem with this commit, but because of other
      code changes it doesn't work on kernels >= 2.6.28 (works if same/similar
      change applied on 2.6.27 for example).
      The issue is as follows: after commit "mac80211: restructure disassoc/deauth
      flows" in 2.6.28, the call to ieee80211_sta_deauthenticate added by
      commit e327b847 will not work: because we do sta_info_flush(local, sdata)
      inside ieee80211_stop (iface.c), all stations in interface are cleared, so
      when calling ieee80211_sta_deauthenticate->ieee80211_set_disassoc (mlme.c),
      inside ieee80211_set_disassoc we have this in the beginning:
               sta = sta_info_get(local, ifsta->bssid);
               if (!sta) {
      The !sta check triggers, thus the function returns early and
      ieee80211_sta_send_apinfo(sdata, ifsta) later isn't called, so
      wpa_supplicant/userspace isn't notified with SIOCGIWAP.
      This commit moves deauthentication to before flushing STA info
      (sta_info_flush), thus the above can't happen and userspace is really
      notified when interface goes down.
      Signed-off-by: default avatarHerton Ronaldo Krzesinski <herton@mandriva.com.br>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Helmut Schaa's avatar
      mac80211: handle failed scan requests in STA mode · af88b907
      Helmut Schaa authored
      If cfg80211 requests a scan it awaits either a return code != 0 from
      the scan function or the cfg80211_scan_done to be called. In case of
      a STA mac80211's scan function ever returns 0 and queues the scan request.
      If ieee80211_sta_work is executed and ieee80211_start_scan fails for
      some reason cfg80211_scan_done will never be called but cfg80211 still
      thinks the scan was triggered successfully and will refuse any future
      scan requests due to drv->scan_req not being cleaned up.
      If a scan is triggered from within the MLME a similar problem appears. If
      ieee80211_start_scan returns an error, local->scan_req will not be reset
      and mac80211 will refuse any future scan requests.
      Hence, in both cases call ieee80211_scan_failed (which notifies cfg80211
      and resets local->scan_req) if ieee80211_start_scan returns an error.
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Jouni Malinen's avatar
      mac80211: Fix WMM ACM parsing and AC downgrade operation · 0eeb59fe
      Jouni Malinen authored
      Incorrect local->wmm_acm bits were set for AC_BK and AC_BE. Fix this
      and add some comments to make it easier to understand the AC-to-UP(pair)
      mapping. Set the wmm_acm bits (and show WMM debug) even if the driver
      does not implement conf_tx() handler.
      In addition, fix the ACM-based AC downgrade code to not use the
      highest priority in error cases. We need to break the loop to get the
      correct AC_BK value (3) instead of returning 0 (which would indicate
      AC_VO). The comment here was not really very useful either, so let's
      provide somewhat more helpful description of the situation.
      Since it is very unlikely that the ACM flag would be set for AC_BK and
      AC_BE, these bugs are not likely to be seen in real life networks.
      Anyway, better do these things correctly should someone really use
      silly AP configuration (and to pass some functionality tests, too).
      Remove the TODO comment about handling ACM. Downgrading AC is
      perfectly valid mechanism for ACM. Eventually, we may add support for
      WMM-AC and send a request for a TS, but anyway, that functionality
      won't be here at the location of this TODO comment.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Jouni Malinen's avatar
      mac80211: Fix panic on fragmentation with power saving · 055249d2
      Jouni Malinen authored
      It was possible to hit a kernel panic on NULL pointer dereference in
      dev_queue_xmit() when sending power save buffered frames to a STA that
      woke up from sleep. This happened when the buffered frame was requeued
      for transmission in ap_sta_ps_end(). In order to avoid the panic, copy
      the skb->dev and skb->iif values from the first fragment to all other
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  3. 05 Mar, 2009 5 commits
  4. 27 Feb, 2009 15 commits
  5. 13 Feb, 2009 14 commits