1. 08 2月, 2011 31 次提交
  2. 05 2月, 2011 4 次提交
    • 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
    • C
      mac80211: fix race between next beacon dtim and ieee80211_get_buffered_bc · 512119b3
      Christian Lamparter 提交于
      On review of 'zd1211rw: implement beacon fetching and handling
      ieee80211_get_buffered_bc()', Christian Lamparter noted that [1]:
      
         Since zd_beacon_done also uploads the next beacon so long in advance,
         there could be an equally long race between the outdated state of the
         next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
         which -in your case- was uploaded almost a beacon interval ago and
         the xmit of ieee80211_get_buffered_bc *now*.
      
         The dtim bc/mc bit might be not set, when a mc/bc arrived after the
         beacon was uploaded, but before the "beacon done event" from the
         hardware. So, dozing stations don't expect the broadcast traffic
         and of course, they might miss it completely.
      
         It's probably better to fix this in mac80211 (see the attached hack).
      
      [1] http://marc.info/?l=linux-wireless&m=129435041117256&w=2
      
      CC: Christian Lamparter <chunkeey@googlemail.com>
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      512119b3
  3. 04 2月, 2011 5 次提交