1. 09 12月, 2010 3 次提交
  2. 07 12月, 2010 2 次提交
  3. 03 12月, 2010 7 次提交
  4. 02 12月, 2010 6 次提交
  5. 01 12月, 2010 4 次提交
    • S
      ath9k: Fix STA disconnect issue due to received MIC failed bcast frames · 916448e7
      Senthil Balasubramanian 提交于
      AR_RxKeyIdxValid will not be set for bcast/mcast frames and so relying
      this status for MIC failed frames is buggy.
      
      Due to this, MIC failure events for broadcast frames are not sent to
      supplicant resulted in AP disconnecting the STA.
      
      Able to pass Wifi Test case 5.2.18 with this fix.
      
      Cc: Stable <stable@kernel.org> (2.6.36+)
      Signed-off-by: NSenthil Balasubramanian <senthilkumar@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      916448e7
    • 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
    • D
      orinoco: abort scan on interface down · cf63495d
      David Kilroy 提交于
      This fixes the problem causing the following trace:
      
      ------------[ cut here ]------------
      WARNING: at linux-2.6.34/net/wireless/core.c:633 wdev_cleanup_work+0xb7/0xe0 [cfg80211]()
      Hardware name: Latitude C840
      Pid: 707, comm: cfg80211 Not tainted 2.6.34.7-0.5-desktop #1
      Call Trace:
       [<c02065c3>] try_stack_unwind+0x173/0x190
       [<c02051cf>] dump_trace+0x3f/0xe0
       [<c020662b>] show_trace_log_lvl+0x4b/0x60
       [<c0206658>] show_trace+0x18/0x20
       [<c064e0b3>] dump_stack+0x6d/0x72
       [<c02443ae>] warn_slowpath_common+0x6e/0xb0
       [<c0244403>] warn_slowpath_null+0x13/0x20
       [<e2db5497>] wdev_cleanup_work+0xb7/0xe0 [cfg80211]
       [<c025cfa9>] run_workqueue+0x79/0x170
       [<c025d123>] worker_thread+0x83/0xe0
       [<c025fef4>] kthread+0x74/0x80
       [<c0203826>] kernel_thread_helper+0x6/0x10
      ---[ end trace 3f0348b3b0c6f4ff ]---
      
      Reported by: Giacomo Comes <comes@naic.edu>
      Signed-off-by: NDavid Kilroy <kilroyd@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf63495d
  6. 30 11月, 2010 10 次提交
  7. 29 11月, 2010 8 次提交