1. 31 10月, 2009 3 次提交
  2. 28 10月, 2009 1 次提交
  3. 08 10月, 2009 1 次提交
    • J
      mac80211: fix vlan and optimise RX · fbc44bf7
      Johannes Berg 提交于
      When receiving data frames, we can send them only to
      the interface they belong to based on transmitting
      station (this doesn't work for probe requests). Also,
      don't try to handle other frames for AP_VLAN at all
      since those interface should only receive data.
      
      Additionally, the transmit side must check that the
      station we're sending a frame to is actually on the
      interface we're transmitting on, and not transmit
      packets to functions that live on other interfaces,
      so validate that as well.
      
      Another bug fix is needed in sta_info.c where in the
      VLAN case when adding/removing stations we overwrite
      the sdata variable we still need.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fbc44bf7
  4. 30 9月, 2009 1 次提交
    • I
      mac80211: Fix [re]association power saving issue on AP side · 1f08e84f
      Igor Perminov 提交于
      Consider the following step-by step:
      1. A STA authenticates and associates with the AP and exchanges
      traffic.
      2. The STA reports to the AP that it is going to PS state.
      3. Some time later the STA device goes to the stand-by mode (not only
      its wi-fi card, but the device itself) and drops the association state
      without sending a disassociation frame.
      4. The STA device wakes up and begins authentication with an
      Auth frame as it hasn't been authenticated/associated previously.
      
      At the step 4 the AP "remembers" the STA and considers it is still in
      the PS state, so the AP buffers frames, which it has to send to the STA.
      But the STA isn't actually in the PS state and so it neither checks
      TIM bits nor reports to the AP that it isn't power saving.
      Because of that authentication/[re]association fails.
      
      To fix authentication/[re]association stage of this issue, Auth, Assoc
      Resp and Reassoc Resp frames are transmitted disregarding of STA's power
      saving state.
      
      N.B. This patch doesn't fix further data frame exchange after
      authentication/[re]association. A patch in hostapd is required to fix
      that.
      Signed-off-by: NIgor Perminov <igor.perminov@inbox.ru>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1f08e84f
  5. 01 9月, 2009 1 次提交
  6. 14 8月, 2009 6 次提交
  7. 05 8月, 2009 1 次提交
    • L
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      Luis R. Rodriguez 提交于
      The mac80211 workqueue exists to enable mac80211 and drivers
      to queue their own work on a single threaded workqueue. mac80211
      takes care to flush the workqueue during suspend but we never
      really had requirements on drivers for how they should use
      the workqueue in consideration for suspend.
      
      We extend mac80211 to document how the mac80211 workqueue should
      be used, how it should not be used and finally move raw access to
      the workqueue to mac80211 only. Drivers and mac80211 use helpers
      to queue work onto the mac80211 workqueue:
      
        * ieee80211_queue_work()
        * ieee80211_queue_delayed_work()
      
      These helpers will now warn if mac80211 already completed its
      suspend cycle and someone is trying to queue work. mac80211
      flushes the mac80211 workqueue prior to suspend a few times,
      but we haven't taken the care to ensure drivers won't add more
      work after suspend. To help with this we add a warning when
      someone tries to add work and mac80211 already completed the
      suspend cycle.
      
      Drivers should ensure they cancel any work or delayed work
      in the mac80211 stop() callback.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      42935eca
  8. 30 7月, 2009 1 次提交
    • J
      mac80211: verify info->control.vif is not NULL · a7bc376c
      Johannes Berg 提交于
      When enqueuing packets on the internal packet queue, we
      need to ensure that we have a valid vif pointer since
      that is required since the net namespace work. Add some
      assertions to verify this, but also don't crash is for
      some reason we don't end up with a vif pointer -- warn
      and drop the packet in all these cases.
      
      Since this code touches a number of hotpaths, it is
      intended to be temporary, or maybe configurable in the
      future, at least the bit that is in the path that gets
      hit for every packet, ieee80211_tx_pending().
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a7bc376c
  9. 28 7月, 2009 5 次提交
  10. 25 7月, 2009 4 次提交
  11. 22 7月, 2009 1 次提交
  12. 06 7月, 2009 1 次提交
  13. 13 6月, 2009 1 次提交
  14. 11 6月, 2009 3 次提交
  15. 04 6月, 2009 1 次提交
  16. 21 5月, 2009 1 次提交
  17. 14 5月, 2009 1 次提交
  18. 07 5月, 2009 3 次提交
  19. 05 5月, 2009 1 次提交
  20. 25 4月, 2009 1 次提交
    • J
      wireless: remove some (bogus?) 'may be used uninitialized' warnings · d3feaf5a
      John W. Linville 提交于
      net/mac80211/tx.c: In function ‘ieee80211_tx_h_select_key’:
      net/mac80211/tx.c:448: warning: ‘key’ may be used uninitialized in this function
      
      drivers/net/wireless/ath/ath9k/rc.c: In function ‘ath_rc_rate_getidx’:
      drivers/net/wireless/ath/ath9k/rc.c:815: warning: ‘nextindex’ may be used uninitialized in this function
      
      drivers/net/wireless/hostap/hostap_plx.c: In function ‘prism2_plx_probe’:
      drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_index’ may be used uninitialized in this function
      drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_offset’ may be used uninitialized in this function
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d3feaf5a
  21. 23 4月, 2009 2 次提交