1. 09 Mar, 2010 1 commit
  2. 03 Mar, 2010 1 commit
    • Sujith's avatar
      mac80211: Fix HT rate control configuration · 4fa00437
      Sujith authored
      
      
      Handling HT configuration changes involved setting the channel
      with the new HT parameters and then issuing a rate_update()
      notification to the driver.
      
      This behavior changed after the off-channel changes. Now, the channel
      is not updated with the new HT params in enable_ht() - instead, it
      is now done when the scan work terminates. This results in the driver
      depending on stale information, defaulting to non-HT mode always.
      
      Fix this by passing the new channel type to the driver.
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarSujith <Sujith.Manoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4fa00437
  3. 15 Feb, 2010 1 commit
    • Jouni Malinen's avatar
      cfg80211/mac80211: allow registering for and sending action frames · 026331c4
      Jouni Malinen authored
      
      
      This implements a new command to register for action frames
      that userspace wants to handle instead of the in-kernel
      rejection. It is then responsible for rejecting ones that
      it decided not to handle. There is no unregistration, but
      the socket can be closed for that.
      
      Frames that are not registered for will not be forwarded
      to userspace and will be rejected by the kernel, the
      cfg80211 API helps implementing that.
      
      Additionally, this patch adds a new command that allows
      doing action frame transmission from userspace. It can be
      used either to exchange action frames on the current
      operational channel (e.g., with the AP with which we are
      currently associated) or to exchange off-channel Public
      Action frames with the remain-on-channel command.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      026331c4
  4. 09 Feb, 2010 1 commit
  5. 08 Feb, 2010 2 commits
    • Kalle Valo's avatar
      mac80211: remove get_tx_stats() driver op · 349e6b72
      Kalle Valo authored
      
      
      get_tx_stats() driver operation is not currently used anywhere in mac80211
      and there are no plans to use it in the not-so-near future. So it can go
      without anyone missing it.
      Signed-off-by: default avatarKalle Valo <kalle.valo@iki.fi>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      349e6b72
    • Johannes Berg's avatar
      mac80211: allow station add/remove to sleep · 34e89507
      Johannes Berg authored
      
      
      Many drivers would like to sleep during station
      addition and removal, and currently have a high
      complexity there from not being able to.
      
      This introduces two new callbacks sta_add() and
      sta_remove() that drivers can implement instead
      of using sta_notify() and that can sleep, and
      the new sta_add() callback is also allowed to
      fail.
      
      The reason we didn't do this previously is that
      the IBSS code wants to insert stations from the
      RX path, which is a tasklet, so cannot sleep.
      This patch will keep the station allocation in
      that path, but moves adding the station to the
      driver out of line. Since the addition can now
      fail, we can have IBSS peer structs the driver
      rejected -- in that case we still talk to the
      station but never tell the driver about it in
      the control.sta pointer. If there will ever be
      a driver that has a low limit on the number of
      stations and that cannot talk to any stations
      that are not known to it, we need to do come up
      with a new strategy of handling larger IBSSs,
      maybe quicker expiry or rejecting peers.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      34e89507
  6. 01 Feb, 2010 1 commit
  7. 26 Jan, 2010 1 commit
  8. 25 Jan, 2010 1 commit
  9. 22 Jan, 2010 1 commit
  10. 19 Jan, 2010 1 commit
    • Johannes Berg's avatar
      mac80211: re-enable re-transmission of filtered frames · c6fcf6bc
      Johannes Berg authored
      
      
      In an earlier commit,
      
          mac80211: disable software retry for now
      
          Pavel Roskin reported a problem that seems to be due to
          software retry of already transmitted frames. It turns
          out that we've never done that correctly, but due to
          some recent changes it now crashes in the TX code. I've
          added a comment in the patch that explains the problem
          better and also points to possible solutions -- which
          I can't implement right now.
      
      I disabled software retry of failed/filtered frames
      because it was broken. With the work of the previous
      patches, it now becomes fairly easy to re-enable it
      by adding a flag indicating that the frame shouldn't
      be modified, but still running it through the transmit
      handlers to populate the control information.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c6fcf6bc
  11. 14 Jan, 2010 2 commits
  12. 12 Jan, 2010 6 commits
    • Kalle Valo's avatar
      mac80211: add U-APSD client support · ab13315a
      Kalle Valo authored
      
      
      Add Unscheduled Automatic Power-Save Delivery (U-APSD) client support. The
      idea is that the data frames from the client trigger AP to send the buffered
      frames with ACs which have U-APSD enabled. This decreases latency and makes it
      possible to save even more power.
      
      Driver needs to use IEEE80211_HW_UAPSD to enable the feature. The current
      implementation assumes that firmware takes care of the wakeup and
      hardware needing IEEE80211_HW_PS_NULLFUNC_STACK is not yet supported.
      
      Tested with wl1251 on a Nokia N900 and Cisco Aironet 1231G AP and running
      various test traffic with ping.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ab13315a
    • Kalle Valo's avatar
      mac80211: create Probe Request template · 05e54ea6
      Kalle Valo authored
      
      
      Certain type of hardware, for example wl1251 and wl1271, need a template
      for the Probe Request. Create a function ieee80211_probereq_get() which
      creates the template and drivers send it to hardware.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      05e54ea6
    • Kalle Valo's avatar
      mac80211: add functions to create PS Poll and Nullfunc templates · 7044cc56
      Kalle Valo authored
      
      
      Some hardware, for example wl1251 and wl1271, handle the transmission
      of power save related frames in hardware, but the driver is responsible
      for creating the templates. It's better to create the templates in mac80211,
      that way all drivers can benefit from this.
      
      Add two new functions, ieee80211_pspoll_get() and ieee80211_nullfunc_get()
      which drivers need to call to get the frame. Drivers are also responsible
      for updating the templates after each association.
      
      Also new struct ieee80211_hdr_3addr is added to ieee80211.h to make it
      easy to calculate length of the Nullfunc frame.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7044cc56
    • Jouni Malinen's avatar
      cfg80211/mac80211: Use more generic bitrate mask for rate control · 37eb0b16
      Jouni Malinen authored
      
      
      Extend struct cfg80211_bitrate_mask to actually use a bitfield mask
      instead of just a single fixed or maximum rate index. This change
      itself does not modify the behavior (except for debugfs files), but it
      prepares cfg80211 and mac80211 for a new nl80211 command for setting
      which rates can be used in TX rate control.
      
      Since frames are now going through the rate control algorithm
      unconditionally, the internal IEEE80211_TX_INTFL_RCALGO flag can now
      be removed. The RC implementations can use the rate_idx_mask value to
      optimize their behavior if only a single rate is enabled.
      
      The old max_rate_idx in struct ieee80211_tx_rate_control is maintained
      (but commented as deprecated) for backwards compatibility with existing
      RC implementations. Once these implementations have been updated to
      use the more generic rate_idx_mask, the max_rate_idx value can be
      removed.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      37eb0b16
    • Jouni Malinen's avatar
      mac80211: Select lowest rate based on basic rate set in AP mode · e00cfce0
      Jouni Malinen authored
      
      
      If the basic rate set is configured to not include the lowest rate
      (e.g., basic rate set = 6, 12, 24 Mbps in IEEE 802.11g mode), the AP
      should not send out broadcast frames at 1 Mbps. This type of
      configuration can be used to optimize channel usage in cases where
      there is no need for backwards compatibility with IEEE 802.11b-only
      devices.
      
      In AP mode, mac80211 was unconditionally using the lowest rate for
      Beacon frames and similarly, with all rate control algorithms that use
      rate_control_send_low(), the lowest rate ended up being used for all
      broadcast frames (and all unicast frames that are sent before
      association). Change this to take into account the basic rate
      configuration in AP mode, i.e., use the lowest rate in the basic rate
      set instead of the lowest supported rate when selecting the rate.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e00cfce0
    • Lukáš Turek's avatar
      mac80211: Add new callback set_coverage_class · 310bc676
      Lukáš Turek authored
      
      
      Mac80211 callback to driver set_coverage_class() sets slot time and ACK
      timeout for given IEEE 802.11 coverage class. The callback is optional,
      but it's essential for long distance links.
      Signed-off-by: default avatarLukas Turek <8an@praha12.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      310bc676
  13. 28 Dec, 2009 4 commits
  14. 22 Dec, 2009 1 commit
  15. 21 Dec, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: reduce reliance on netdev · 47846c9b
      Johannes Berg authored
      
      
      For bluetooth 3, we will most likely not have
      a netdev for a virtual interface (sdata), so
      prepare for that by reducing the reliance on
      having a netdev. This patch moves the name
      and address fields into the sdata struct and
      uses them from there all over. Some work is
      needed to keep them sync'ed, but that's not
      a lot of work and in slow paths anyway.
      
      In doing so, this also reduces the number of
      pointer dereferences in many places, because
      of things like sdata->dev->dev_addr becoming
      sdata->vif.addr.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      47846c9b
  16. 14 Dec, 2009 1 commit
  17. 30 Nov, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: fix spurious delBA handling · 827d42c9
      Johannes Berg authored
      Lennert Buytenhek noticed that delBA handling in mac80211
      was broken and has remotely triggerable problems, some of
      which are due to some code shuffling I did that ended up
      changing the order in which things were done -- this was
      
        commit d75636ef
        Author: Johannes Berg <johannes@sipsolutions.net>
        Date:   Tue Feb 10 21:25:53 2009 +0100
      
          mac80211: RX aggregation: clean up stop session
      
      and other parts were already present in the original
      
        commit d92684e6
      
      
        Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
        Date:   Mon Jan 28 14:07:22 2008 +0200
      
            mac80211: A-MPDU Tx add delBA from recipient support
      
      The first problem is that I moved a BUG_ON before various
      checks -- thereby making it possible to hit. As the comment
      indicates, the BUG_ON can be removed since the ampdu_action
      callback must already exist when the state is != IDLE.
      
      The second problem isn't easily exploitable but there's a
      race condition due to unconditionally setting the state to
      OPERATIONAL when a delBA frame is received, even when no
      aggregation session was ever initiated. All the drivers
      accept stopping the session even then, but that opens a
      race window where crashes could happen before the driver
      accepts it. Right now, a WARN_ON may happen with non-HT
      drivers, while the race opens only for HT drivers.
      
      For this case, there are two things necessary to fix it:
       1) don't process spurious delBA frames, and be more careful
          about the session state; don't drop the lock
      
       2) HT drivers need to be prepared to handle a session stop
          even before the session was really started -- this is
          true for all drivers (that support aggregation) but
          iwlwifi which can be fixed easily. The other HT drivers
          (ath9k and ar9170) are behaving properly already.
      Reported-by: default avatarLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      827d42c9
  18. 28 Nov, 2009 1 commit
  19. 19 Nov, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: request TX status where needed · 7351c6bd
      Johannes Berg authored
      
      
      Right now all frames mac80211 hands to the driver
      have the IEEE80211_TX_CTL_REQ_TX_STATUS flag set to
      request TX status. This isn't really necessary, only
      the injected frames need TX status (the latter for
      hostapd) so move setting this flag.
      
      The rate control algorithms also need TX status, but
      they don't require it.
      
      Also, rt2x00 uses that bit for its own purposes and
      seems to require it being set for all frames, but
      that can be fixed in rt2x00.
      
      This doesn't really change anything for any drivers
      but in the future drivers using hw-rate control may
      opt to not report TX status for frames that don't
      have the IEEE80211_TX_CTL_REQ_TX_STATUS flag set.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: Ivo van Doorn <IvDoorn@gmail.com> [rt2x00 bits]
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7351c6bd
  20. 18 Nov, 2009 3 commits
  21. 06 Nov, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: async station powersave handling · af818581
      Johannes Berg authored
      
      
      Some devices require that all frames to a station
      are flushed when that station goes into powersave
      mode before being able to send frames to that
      station again when it wakes up or polls -- all in
      order to avoid reordering and too many or too few
      frames being sent to the station when it polls.
      
      Normally, this is the case unless the station
      goes to sleep and wakes up very quickly again.
      But in that case, frames for it may be pending
      on the hardware queues, and thus races could
      happen in the case of multiple hardware queues
      used for QoS/WMM. Normally this isn't a problem,
      but with the iwlwifi mechanism we need to make
      sure the race doesn't happen.
      
      This makes mac80211 able to cope with the race
      with driver help by a new WLAN_STA_PS_DRIVER
      per-station flag that can be controlled by the
      driver and tells mac80211 whether it can transmit
      frames or not. This flag must be set according to
      very specific rules outlined in the documentation
      for the function that controls it.
      
      When we buffer new frames for the station, we
      normally set the TIM bit right away, but while
      the driver has blocked transmission to that sta
      we need to avoid that as well since we cannot
      respond to the station if it wakes up due to the
      TIM bit. Once the driver unblocks, we can set
      the TIM bit.
      
      Similarly, when the station just wakes up, we
      need to wait until all other frames are flushed
      before we can transmit frames to that station,
      so the same applies here, we need to wait for
      the driver to give the OK.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      af818581
  22. 04 Nov, 2009 1 commit
  23. 30 Oct, 2009 3 commits
    • Johannes Berg's avatar
      mac80211: deprecate qual value · c27f2fde
      Johannes Berg authored
      
      
      This value is unused by mac80211, because it was only
      be used by wireless extensions, and turned out to not
      be useful there because the quality value needs to be
      comparable between scan results and the current value
      which is impossible when the qual value is calculated
      taking into account noise, for example.
      
      Since it is unused anyway, this patch deprecates it
      in the hope that drivers will remove their sometimes
      quite expensive calculations of the value.
      
      I'm open to actual uses of the value, but the best
      way of using it seems to be what the Intel drivers do
      which should probably be generalised if we have noise
      values from the hardware.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      c27f2fde
    • Johannes Berg's avatar
      mac80211: introduce ieee80211_beacon_get_tim() · eddcbb94
      Johannes Berg authored
      
      
      Compared to ieee80211_beacon_get(), the new function
      ieee80211_beacon_get_tim() returns information on the
      location and length of the TIM IE, which some drivers
      need in order to generate the TIM on the device. The
      old function, ieee80211_beacon_get(), becomes a small
      static inline wrapper around the new one to not break
      all drivers.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      eddcbb94
    • Johannes Berg's avatar
      mac80211: remove RX_FLAG_RADIOTAP · 0869aea0
      Johannes Berg authored
      
      
      While there may be a case for a driver adding its
      own bits of radiotap information, none currently
      does. Also, drivers would have to copy the code
      to generate the radiotap bits that now mac80211
      generates. If some driver in the future needs to
      add some driver-specific information I'd expect
      that to be in a radiotap vendor namespace and we
      can add a different way of passing such data up
      and having mac80211 include it.
      
      Additionally, rename IEEE80211_CONF_RADIOTAP to
      IEEE80211_CONF_MONITOR since it's still used by
      b43(legacy) to obtain per-frame timestamps.
      
      The purpose of this patch is to simplify the RX
      code in mac80211 to make it easier to add paged
      skb support.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0869aea0
  24. 27 Oct, 2009 1 commit
  25. 12 Oct, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: document ieee80211_rx() context requirement · d20ef63d
      Johannes Berg authored
      
      
      ieee80211_rx() must be called with softirqs disabled
      since the networking stack requires this for netif_rx()
      and some code in mac80211 can assume that it can not
      be processing its own tasklet and this call at the same
      time.
      
      It may be possible to remove this requirement after a
      careful audit of mac80211 and doing any needed locking
      improvements in it along with disabling softirqs around
      netif_rx(). An alternative might be to push all packet
      processing to process context in mac80211, instead of
      to the tasklet, and add other synchronisation.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d20ef63d
  26. 28 Aug, 2009 1 commit