1. 12 5月, 2011 2 次提交
  2. 03 5月, 2011 1 次提交
  3. 27 4月, 2011 1 次提交
  4. 20 4月, 2011 1 次提交
  5. 14 4月, 2011 1 次提交
  6. 13 4月, 2011 1 次提交
  7. 05 4月, 2011 1 次提交
  8. 31 3月, 2011 1 次提交
  9. 29 3月, 2011 1 次提交
    • D
      mac80211: fix aggregation frame release during timeout · 499fe9a4
      Daniel Halperin 提交于
      Suppose the aggregation reorder buffer looks like this:
      
      x-T-R1-y-R2,
      
      where x and y are frames that have not been received, T is a received
      frame that has timed out, and R1,R2 are received frames that have not
      yet timed out. The proper behavior in this scenario is to move the
      window past x (skipping it), release T and R1, and leave the window at y
      until y is received or R2 times out.
      
      As written, this code will instead leave the window at R1, because it
      has not yet timed out. Fix this by exiting the reorder loop only when
      the frame that has not timed out AND there are skipped frames earlier in
      the current valid window.
      Signed-off-by: NDaniel Halperin <dhalperi@cs.washington.edu>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      499fe9a4
  10. 02 3月, 2011 1 次提交
  11. 24 2月, 2011 1 次提交
  12. 15 2月, 2011 1 次提交
  13. 08 2月, 2011 2 次提交
  14. 05 2月, 2011 3 次提交
    • B
      mac80211: Optimize scans on current operating channel. · b23b025f
      Ben Greear 提交于
      This should decrease un-necessary flushes, on/off channel work,
      and channel changes in cases where the only scanned channel is
      the current operating channel.
      
      * Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
        and is-scanning flags instead.
      
      * Add helper method to determine if we are currently configured
        for the operating channel.
      
      * Do no blindly go off/on channel in work.c  Instead, only call
        appropriate on/off code when we really need to change channels.
        Always enable offchannel-ps mode when starting work,
        and disable it when we are done.
      
      * Consolidate ieee80211_offchannel_stop_station and
        ieee80211_offchannel_stop_beaconing, call it
        ieee80211_offchannel_stop_vifs instead.
      
      * Accept non-beacon frames when scanning on operating channel.
      
      * Scan state machine optimized to minimize on/off channel
        transitions.  Also, when going on-channel, go ahead and
        re-enable beaconing.  We're going to be there for 200ms,
        so seems like some useful beaconing could happen.
        Always enable offchannel-ps mode when starting software
        scan, and disable it when we are done.
      
      * Grab local->mtx earlier in __ieee80211_scan_completed_finish
        so that we are protected when calling hw_config(), etc.
      
      * Pass probe-responses up the stack if scanning on local
        channel, so that mlme can take a look.
      Signed-off-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b23b025f
    • F
      mac80211: do not send duplicate data frames to the cooked monitor interface · b1f93314
      Felix Fietkau 提交于
      I can't think of a valid use case for this aside from debugging (which can
      also be done with a real monitor interface), and dropping these frames saves
      some precious CPU cycles.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b1f93314
    • R
      mac80211: do not restart ps timer during scan or offchannel · 8c99f691
      Rajkumar Manoharan 提交于
      While leaving oper channel, STA informs sleep state to AP to
      stop sending data. Till sending ack for the nullfunc, AP
      continues to send the data to STA which restarts ps_timer that
      is causing unnecessary nullfunc exchange on timer expiry
      when the STA was already moved to offchannel. So don't restart ps_timer
      on data reception during scan. This issue was identified by
      the following warning.
      
      WARNING: at net/mac80211/tx.c:661 invoke_tx_handlers+0xf07/0x1330 [mac80211]
      wlan0: Dropped data frame as no usable bitrate found while scanning and
      associated. Target station: 00:03:7f:0b:a6:1b on 5 GHz band
      Call Trace:
        [<ffffffffa0413ba7>] invoke_tx_handlers+0xf07/0x1330 [mac80211]
        [<ffffffffa0414056>] ieee80211_tx+0x86/0x2c0 [mac80211]
        [<ffffffffa0414345>] ieee80211_xmit+0xb5/0x1d0 [mac80211]
        [<ffffffffa04037e0>] ieee80211_dynamic_ps_enable_work+0x0/0xb0 [mac80211]
        [<ffffffffa04158cf>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
        [<ffffffffa04026e6>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
        [<ffffffffa0403885>] ieee80211_dynamic_ps_enable_work+0xa5/0xb0 [mac80211]
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8c99f691
  15. 04 2月, 2011 2 次提交
  16. 29 1月, 2011 1 次提交
  17. 22 1月, 2011 1 次提交
  18. 20 1月, 2011 1 次提交
    • F
      mac80211: drop non-auth 3-addr data frames when running as a 4-addr station · fbb327c5
      Felix Fietkau 提交于
      When running as a 4-addr station against an AP that has the 4-addr VLAN
      interface and the main 3-addr AP interface bridged together, sometimes
      frames originating from the station were looping back from the 3-addr AP
      interface, causing the bridge code to emit warnings about receiving frames
      with its own source address.
      I'm not sure why this is happening yet, but I think it's a good idea to
      drop all frames (except 802.1x/EAP frames) that do not match the configured
      addressing mode, including 4-address frames sent to a 3-address station.
      User test reports indicate that the problem goes away with this patch.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fbb327c5
  19. 05 1月, 2011 4 次提交
  20. 23 12月, 2010 2 次提交
  21. 21 12月, 2010 1 次提交
  22. 17 12月, 2010 1 次提交
    • J
      nl80211: Add notification for dropped Deauth/Disassoc · cf4e594e
      Jouni Malinen 提交于
      Add a new notification to indicate that a received, unprotected
      Deauthentication or Disassociation frame was dropped due to
      management frame protection being in use. This notification is
      needed to allow user space (e.g., wpa_supplicant) to implement
      SA Query procedure to recover from association state mismatch
      between an AP and STA.
      
      This is needed to avoid getting stuck in non-working state when MFP
      (IEEE 802.11w) is used and a protected Deauthentication or
      Disassociation frame is dropped for any reason. After that, the
      station would silently discard any unprotected Deauthentication or
      Disassociation frame that could be indicating that the AP does not
      have association for the STA (when the Reason Code would be 6 or 7).
      IEEE Std 802.11w-2009, 11.13 describes this recovery mechanism.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      cf4e594e
  23. 14 12月, 2010 1 次提交
  24. 08 12月, 2010 1 次提交
  25. 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
  26. 30 11月, 2010 1 次提交
  27. 25 11月, 2010 1 次提交
  28. 19 11月, 2010 1 次提交
  29. 18 11月, 2010 1 次提交
    • 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