1. 07 12月, 2010 4 次提交
  2. 02 12月, 2010 16 次提交
  3. 01 12月, 2010 3 次提交
    • H
      mac80211: Minor optimization in ieee80211_rx_h_data · 08ca944e
      Helmut Schaa 提交于
      Remove a superfluous ieee80211_is_data check as that was checked a few
      lines before already and we wont't get here for non-data frames at all.
      
      Second, the frame was already converted to 802.3 header format and
      reading the fc and addr1 fields was only possible because the 802.3
      header is short enough and didn't overwrite the relevant parts of the
      802.11 header. Make the code more obvious by checking the ethernet
      header's h_dest field.
      
      Furthermore reorder the conditions to reduce the number of checks
      when dynamic powersave is not needed (AP mode for example).
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      08ca944e
    • 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
  4. 30 11月, 2010 4 次提交
  5. 25 11月, 2010 11 次提交
  6. 23 11月, 2010 2 次提交
    • H
      mac80211: Disable hw crypto for GTKs on AP VLAN interfaces · 18890d4b
      Helmut Schaa 提交于
      When using AP VLAN interfaces, each VLAN interface should be in its own
      broadcast domain. Hostapd achieves this by assigning different GTKs to
      different AP VLAN interfaces.
      
      However, mac80211 drivers are not aware of AP VLAN interfaces and as
      such mac80211 sends the GTK to the driver in the context of the base AP
      mode interface. This causes problems when multiple AP VLAN interfaces
      are used since the driver will use the same key slot for the different
      GTKs (there's no way for the driver to distinguish the different GTKs
      from different AP VLAN interfaces). Thus, only the clients associated
      to one AP VLAN interface (the one that was created last) can actually
      use broadcast traffic.
      
      Fix this by not programming any GTKs for AP VLAN interfaces into the hw
      but fall back to using software crypto. The GTK for the underlying AP
      interface is still sent to the driver.
      
      That means, broadcast traffic to stations associated to an AP VLAN
      interface is encrypted in software whereas broadcast traffic to
      stations associated to the non-VLAN AP interface is encrypted in
      hardware.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      18890d4b
    • L
      cfg80211: Fix regulatory bug with multiple cards and delays · b2e253cf
      Luis R. Rodriguez 提交于
      When two cards are connected with the same regulatory domain
      if CRDA had a delayed response then cfg80211's own set regulatory
      domain would still be the world regulatory domain. There was a bug
      on cfg80211's logic such that it assumed that once you pegged a
      request as the last request it was already the currently set
      regulatory domain. This would mean we would race setting a stale
      regulatory domain to secondary cards which had the same regulatory
      domain since the alpha2 would match.
      
      We fix this by processing each regulatory request atomically,
      and only move on to the next one once we get it fully processed.
      In the case CRDA is not present we will simply world roam.
      
      This issue is only present when you have a slow system and the
      CRDA processing is delayed. Because of this it is not a known
      regression.
      
      Without this fix when a delay is present with CRDA the second card
      would end up with an intersected regulatory domain and not allow it
      to use the channels it really is designed for. When two cards with
      two different regulatory domains were inserted you'd end up
      rejecting the second card's regulatory domain request.
      This fails with mac80211_hswim's regtest=2 (two requests, same alpha2)
      and regtest=3 (two requests, different alpha2) module parameter
      options.
      
      This was reproduced and tested against mac80211_hwsim using this
      CRDA delayer:
      
             #!/bin/bash
             echo $COUNTRY >> /tmp/log
             sleep 2
             /sbin/crda.orig
      
      And these regulatory tests:
      
             modprobe mac80211_hwsim regtest=2
             modprobe mac80211_hwsim regtest=3
      Reported-by: NMark Mentovai <mark@moxienet.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Tested-by: NMark Mentovai <mark@moxienet.com>
      Tested-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b2e253cf