1. 08 12月, 2010 1 次提交
  2. 07 12月, 2010 7 次提交
  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 9 次提交
  6. 23 11月, 2010 1 次提交
    • 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
  7. 19 11月, 2010 1 次提交
  8. 18 11月, 2010 2 次提交
    • J
      mac80211: fix powersaving clients races · 50a9432d
      Johannes Berg 提交于
      The code to handle powersaving stations has a race:
      when the powersave flag is lifted from a station,
      we could transmit a packet that is being processed
      for TX at the same time right away, even if there
      are other frames queued for it. This would cause
      frame reordering. To fix this, lift the flag only
      under the appropriate lock that blocks TX.
      
      Additionally, the code to allow drivers to block a
      station while frames for it are on the HW queue is
      never re-enabled the station, so traffic would get
      stuck indefinitely. Fix this by clearing the flag
      for this appropriately.
      
      Finally, as an optimisation, don't do anything if
      the driver unblocks an already unblocked station.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      50a9432d
    • J
      mac80211: defines for AC numbers · 4bce22b9
      Johannes Berg 提交于
      In many places we've just hardcoded the
      AC numbers -- which is a relic from the
      original mac80211 (d80211). Add constants
      for them so we know what we're talking
      about.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4bce22b9
  9. 17 11月, 2010 4 次提交
  10. 16 11月, 2010 3 次提交
  11. 09 11月, 2010 1 次提交
    • B
      mac80211: unset SDATA_STATE_OFFCHANNEL when cancelling a scan · 352ffad6
      Brian Cavagnolo 提交于
      For client STA interfaces, ieee80211_do_stop unsets the relevant
      interface's SDATA_STATE_RUNNING state bit prior to cancelling an
      interrupted scan.  When ieee80211_offchannel_return is invoked as
      part of cancelling the scan, it doesn't bother unsetting the
      SDATA_STATE_OFFCHANNEL bit because it sees that the interface is
      down.  Normally this doesn't matter because when the client STA
      interface is brought back up, it will probably issue a scan.  But
      in some cases (e.g., the user changes the interface type while it
      is down), the SDATA_STATE_OFFCHANNEL bit will remain set.  This
      prevents the interface queues from being started.  So we
      cancel the scan before unsetting the SDATA_STATE_RUNNING bit.
      Signed-off-by: NBrian Cavagnolo <brian@cozybit.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      352ffad6
  12. 30 10月, 2010 1 次提交
    • J
      mac80211: fix failure to check kmalloc return value in key_key_read · 520efd1a
      Jesper Juhl 提交于
      I noticed two small issues in mac80211/debugfs_key.c::key_key_read while
      reading through the code. Patch below.
      
      The key_key_read() function returns ssize_t and the value that's actually
      returned is the return value of simple_read_from_buffer() which also
      returns ssize_t, so let's hold the return value in a ssize_t local
      variable rather than a int one.
      
      Also, memory is allocated dynamically with kmalloc() which can fail, but
      the return value of kmalloc() is not checked, so we may end up operating
      on a null pointer further on. So check for a NULL return and bail out with
      -ENOMEM in that case.
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      520efd1a
  13. 28 10月, 2010 1 次提交
  14. 26 10月, 2010 2 次提交