1. 01 12月, 2010 2 次提交
    • S
      mac80211: Fix STA disconnect due to MIC failure · 8e26d5ad
      Senthil Balasubramanian 提交于
      Th commit titled "mac80211: clean up rx handling wrt. found_sta"
      removed found_sta variable which caused a MIC failure event
      to be reported twice for a single failure to supplicant resulted
      in STA disconnect.
      
      This should fix WPA specific countermeasures WiFi test case (5.2.17)
      issues with mac80211 based drivers which report MIC failure events in
      rx status.
      
      Cc: Stable <stable@kernel.org> (2.6.37)
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e26d5ad
    • C
      mac80211: ignore non-bcast mcast deauth/disassoc franes · 2c31333a
      Christian Lamparter 提交于
      This patch fixes an curious issue due to insufficient
      rx frame filtering.
      
      Saqeb Akhter reported frequent disconnects while streaming
      videos over samba: <http://marc.info/?m=128600031109136>
      > [ 1166.512087] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
      > [ 1526.059997] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
      > [ 2125.324356] wlan1: deauthenticated from 30:46:9a:10:49:f7 (Reason: 7)
      > [...]
      
      The reason is that the device generates frames with slightly
      bogus SA/TA addresses.
      
      e.g.:
       [ 2314.402316] Ignore 9f:1f:31:f8:64:ff
       [ 2314.402321] Ignore 9f:1f:31:f8:64:ff
       [ 2352.453804] Ignore 0d:1f:31:f8:64:ff
       [ 2352.453808] Ignore 0d:1f:31:f8:64:ff
       					   ^^ the group-address flag is set!
       (the correct SA/TA would be: 00:1f:31:f8:64:ff)
      
      Since the AP does not know from where the frames come, it
      generates a DEAUTH response for the (invalid) mcast address.
      This mcast deauth frame then passes through all filters and
      tricks the stack into thinking that the AP brutally kicked
      us!
      
      This patch fixes the problem by simply ignoring
      non-broadcast, group-addressed deauth/disassoc frames.
      
      Cc: Jouni Malinen <j@w1.fi>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Reported-by: NSaqeb Akhter <saqeb.akhter@gmail.com>
      Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      2c31333a
  2. 12 10月, 2010 1 次提交
  3. 07 10月, 2010 1 次提交
  4. 06 10月, 2010 1 次提交
  5. 28 9月, 2010 7 次提交
  6. 25 9月, 2010 1 次提交
    • J
      mac80211: fix use-after-free · cd87a2d3
      Johannes Berg 提交于
      commit 8c0c709e
      Author: Johannes Berg <johannes@sipsolutions.net>
      Date:   Wed Nov 25 17:46:15 2009 +0100
      
          mac80211: move cmntr flag out of rx flags
      
      moved the CMTR flag into the skb's status, and
      in doing so introduced a use-after-free -- when
      the skb has been handed to cooked monitors the
      status setting will touch now invalid memory.
      
      Additionally, moving it there has effectively
      discarded the optimisation -- since the bit is
      only ever set on freed SKBs, and those were a
      copy, it could never be checked.
      
      For the current release, fixing this properly
      is a bit too involved, so let's just remove the
      problematic code and leave userspace with one
      copy of each frame for each virtual interface.
      
      Cc: stable@kernel.org [2.6.33+]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cd87a2d3
  7. 17 9月, 2010 1 次提交
  8. 28 8月, 2010 2 次提交
  9. 26 8月, 2010 2 次提交
  10. 25 8月, 2010 1 次提交
  11. 17 8月, 2010 6 次提交
  12. 29 6月, 2010 1 次提交
  13. 24 6月, 2010 1 次提交
  14. 16 6月, 2010 1 次提交
  15. 15 6月, 2010 7 次提交
  16. 05 6月, 2010 1 次提交
    • J
      mac80211: process station blockack action frames from work · 8b9a4e6e
      Johannes Berg 提交于
      Processing an association response could take a bit
      of time while we set up the hardware etc. During that
      time, the AP might already send a blockack request.
      If this happens very quickly on a fairly slow machine,
      we can end up processing the blockack request before
      the association processing has finished. Since the
      blockack processing cannot sleep right now, we also
      cannot make it wait in the driver.
      
      As a result, sometimes on slow machines the iwlagn
      driver gets totally confused, and no traffic can pass
      when the aggregation setup was done before the assoc
      setup completed.
      
      I'm working on a proper fix for this, which involves
      queuing all blockack category action frames from a
      work struct, and also allowing the ampdu_action driver
      callback to sleep, which will generally clean up the
      code and make things easier.
      
      However, this is a very involved and complex change.
      To fix the problem at hand in a way that can also be
      backported to stable, I've come up with this patch.
      Here, I simply process all aggregation action frames
      from the managed interface skb queue, which means
      their processing will be serialized with processing
      the association response, thereby fixing the problem.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8b9a4e6e
  17. 04 6月, 2010 2 次提交
  18. 03 6月, 2010 1 次提交
  19. 02 6月, 2010 1 次提交