1. 28 7月, 2009 3 次提交
    • H
      mac80211: implement basic background scanning · 142b9f50
      Helmut Schaa 提交于
      Introduce a new scan flag "SCAN_OFF_CHANNEL" which basically tells us
      that we are currently on a different channel for scanning and cannot
      RX/TX. "SCAN_SW_SCANNING" tells us that we are currently running a
      software scan but we might as well be on the operating channel to RX/TX.
      While "SCAN_SW_SCANNING" is set during the whole scan "SCAN_OFF_CHANNEL"
      is set when leaving the operating channel and unset when coming back.
      
      Introduce two new scan states "SCAN_LEAVE_OPER_CHANNEL" and
      "SCAN_ENTER_OPER_CHANNEL" which basically implement the functionality we
      need to leave the operating channel (send a nullfunc to the AP and stop
      the queues) and enter it again (send a nullfunc to the AP and start the
      queues again).
      
      Enhance the scan state "SCAN_DECISION" to switch back to the operating
      channel after each scanned channel. In the future it sould be simple
      to enhance the decision state to scan as much channels in a row as the
      qos latency allows us.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      142b9f50
    • H
      mac80211: Replace {sw, hw}_scanning variables with a bitfield · fbe9c429
      Helmut Schaa 提交于
      Use a bitfield to store the current scan mode instead of two boolean
      variables {sw,hw}_scanning. This patch does not introduce functional
      changes but allows us to enhance the scan flags later (for example
      for background scanning).
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      fbe9c429
    • J
      mac80211: cooperate more with network namespaces · 5061b0c2
      Johannes Berg 提交于
      There are still two places in mac80211 that hardcode
      the initial net namespace (init_net). One of them is
      mandated by cfg80211 and will be removed by a separate
      patch, the other one is used for finding the network
      device of a pending packet via its ifindex.
      
      Remove the latter use by keeping track of the device
      pointer itself, via the vif pointer, and avoid it
      going stale by dropping pending frames for a given
      interface when the interface is removed.
      
      To keep track of the vif pointer for the correct
      interface, change the info->control.vif pointer's
      internal use to always be the correct vif, and only
      move it to the vif the driver expects (or NULL for
      monitor interfaces and injected packets) right before
      giving the packet to the driver.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5061b0c2
  2. 25 7月, 2009 4 次提交
  3. 22 7月, 2009 1 次提交
  4. 06 7月, 2009 1 次提交
  5. 13 6月, 2009 1 次提交
  6. 11 6月, 2009 3 次提交
  7. 04 6月, 2009 1 次提交
  8. 21 5月, 2009 1 次提交
  9. 14 5月, 2009 1 次提交
  10. 07 5月, 2009 3 次提交
  11. 05 5月, 2009 1 次提交
  12. 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
  13. 23 4月, 2009 3 次提交
  14. 28 3月, 2009 9 次提交
  15. 17 3月, 2009 1 次提交
  16. 28 2月, 2009 2 次提交
    • J
      mac80211: split IBSS/managed code · 46900298
      Johannes Berg 提交于
      This patch splits out the ibss code and data from managed (station) mode.
      The reason to do this is to better separate the state machines, and have
      the code be contained better so it gets easier to determine what exactly
      a given change will affect, that in turn makes it easier to understand.
      
      This is quite some churn, especially because I split sdata->u.sta into
      sdata->u.mgd and sdata->u.ibss, but I think it's easier to maintain that
      way. I've also shuffled around some code -- null function sending is only
      applicable to managed interfaces so put that into that file, some other
      functions are needed from various places so put them into util, and also
      rearranged the prototypes in ieee80211_i.h accordingly.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      46900298
    • J
      mac80211: fix aggregation for hardware with ampdu queues · 96f5e66e
      Johannes Berg 提交于
      Hardware with AMPDU queues currently has broken aggregation.
      
      This patch fixes it by making all A-MPDUs go over the regular AC queues,
      but keeping track of the hardware queues in mac80211. As a first rough
      version, it actually stops the AC queue for extended periods of time,
      which can be removed by adding buffering internal to mac80211, but is
      currently not a huge problem because people rarely use multiple TIDs
      that are in the same AC (and iwlwifi currently doesn't operate as AP).
      
      This is a short-term fix, my current medium-term plan, which I hope to
      execute soon as well, but am not sure can finish before .30, looks like
      this:
       1) rework the internal queuing layer in mac80211 that we use for
          fragments if the driver stopped queue in the middle of a fragmented
          frame to be able to queue more frames at once (rather than just a
          single frame with its fragments)
       2) instead of stopping the entire AC queue, queue up the frames in a
          per-station/per-TID queue during aggregation session initiation,
          when the session has come up take all those frames and put them
          onto the queue from 1)
       3) push the ampdu queue layer abstraction this patch introduces in
          mac80211 into the driver, and remove the virtual queue stuff from
          mac80211 again
      
      This plan will probably also affect ath9k in that mac80211 queues the
      frames instead of passing them down, even when there are no ampdu queues.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      96f5e66e
  17. 14 2月, 2009 1 次提交
  18. 12 2月, 2009 1 次提交
  19. 10 2月, 2009 1 次提交
    • L
      mac80211: do not TX injected frames when not allowed · 47f4d887
      Luis R. Rodriguez 提交于
      Monitor mode is able to TX by using injected frames. We should
      not allow injected frames to be sent unless allowed by regulatory
      rules. Since AP mode uses a monitor interfaces to transmit
      management frames we have to take care to not break AP mode as
      well while resolving this. We can deal with this by allowing compliant
      APs solutions to inform mac80211 if their monitor interface is
      intended to be used for an AP by setting a cfg80211 flag for the
      monitor interface. hostapd, for example, currently does its own
      checks to ensure AP mode is not used on channels which require radar
      detection. Once such solutions are available it can can add this
      flag for monitor interfaces.
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      47f4d887
  20. 30 1月, 2009 1 次提交
    • J
      mac80211: Fix drop-unencrypted for management frames · e0463f50
      Jouni Malinen 提交于
      ADDBA request Action frame was sent out before 4-way handshake was
      completed and the initial 802.11w code ended up dropping the frame
      even if MFP was not enabled. While the sending of Action frames this
      early is not really a good idea (will break with MFP enabled), we
      should not break this for the MFP disabled case.
      
      This patch fixes ieee80211_tx_h_select_key() not to drop management
      frames if MFP is disabled. If MFP is enabled, Action frames will be
      dropped before keys are set per IEEE 802.11w/D7.0. Other robust
      management frames (i.e., Deauthentication and Disassociation frames)
      are allowed unprotected prior to key configuration.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e0463f50