1. 22 3月, 2011 1 次提交
  2. 04 2月, 2011 1 次提交
  3. 08 12月, 2010 1 次提交
  4. 25 11月, 2010 1 次提交
  5. 19 11月, 2010 1 次提交
  6. 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
  7. 07 10月, 2010 2 次提交
  8. 28 9月, 2010 1 次提交
  9. 17 9月, 2010 1 次提交
  10. 15 9月, 2010 1 次提交
  11. 26 8月, 2010 1 次提交
  12. 28 7月, 2010 1 次提交
    • J
      mac80211: Fix key freeing to handle unlinked keys · 32162a4d
      Jouni Malinen 提交于
      Key locking simplification removed key->sdata != NULL verification from
      ieee80211_key_free(). While that is fine for most use cases, there is one
      path where this function can be called with an unlinked key (i.e.,
      key->sdata == NULL && key->local == NULL). This results in a NULL pointer
      dereference with the current implementation. This is known to happen at
      least with FT protocol when wpa_supplicant tries to configure the key
      before association.
      
      Avoid the issue by passing in the local pointer to
      ieee80211_key_free(). In addition, do not clear the key from hw_accel
      or debugfs if it has not yet been added. At least the hw_accel one could
      trigger another NULL pointer dereference.
      Signed-off-by: NJouni Malinen <j@w1.fi>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      32162a4d
  13. 15 6月, 2010 4 次提交
  14. 04 6月, 2010 1 次提交
  15. 25 5月, 2010 1 次提交
  16. 04 5月, 2010 1 次提交
  17. 20 4月, 2010 1 次提交
  18. 09 4月, 2010 1 次提交
  19. 08 4月, 2010 2 次提交
    • J
      mac80211: clean up/fix aggregation code · 098a6070
      Johannes Berg 提交于
      The aggregation code has a number of quirks, like
      inventing an unneeded WLAN_BACK_TIMER value and
      leaking memory under certain circumstances during
      station destruction. Fix these issues by using
      the regular aggregation session teardown code and
      blocking new aggregation sessions, all before the
      station is really destructed.
      
      As a side effect, this gets rid of the long code
      block to destroy aggregation safely.
      
      Additionally, rename tid_state_rx which can only
      have the values IDLE and OPERATIONAL to
      tid_active_rx to make it easier to understand
      that there is no bitwise stuff going on on the
      RX side -- the TX side remains because it needs
      to keep track of the driver and peer states.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      098a6070
    • J
      mac80211: fix station destruction problem · e64b3795
      Johannes Berg 提交于
      When a station w/o a key is destroyed, or when
      a driver submits work for a station and thereby
      references it again, it seems like potentially
      we could reference the station structure while
      it is being destroyed.
      
      Wait for an RCU grace period to elapse before
      finishing destroying the station after we have
      removed the station from the driver and from
      the hash table etc., even in the case where no
      key is associated with the station.
      
      Also, there's no point in deleting the plink
      timer here since it'll be properly deleted just
      a bit later.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e64b3795
  20. 07 4月, 2010 1 次提交
  21. 11 3月, 2010 1 次提交
  22. 09 2月, 2010 1 次提交
    • J
      mac80211: allow station add/remove to sleep · 34e89507
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      34e89507
  23. 13 1月, 2010 1 次提交
  24. 29 12月, 2009 2 次提交
  25. 22 12月, 2009 3 次提交
  26. 19 11月, 2009 2 次提交
  27. 12 11月, 2009 1 次提交
    • F
      mac80211: implement support for 4-address frames for AP and client mode · f14543ee
      Felix Fietkau 提交于
      In some situations it might be useful to run a network with an
      Access Point and multiple clients, but with each client bridged
      to a network behind it. For this to work, both the client and the
      AP need to transmit 4-address frames, containing both source and
      destination MAC addresses.
      With this patch, you can configure a client to communicate using
      only 4-address frames for data traffic.
      On the AP side you can enable 4-address frames for individual
      clients by isolating them in separate AP VLANs which are configured
      in 4-address mode.
      Such an AP VLAN will be limited to one client only, and this client
      will be used as the destination for all traffic on its interface,
      regardless of the destination MAC address in the packet headers.
      The advantage of this mode compared to regular WDS mode is that it's
      easier to configure and does not require a static list of peer MAC
      addresses on any side.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f14543ee
  28. 07 11月, 2009 1 次提交
    • J
      mac80211: async station powersave handling · af818581
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af818581
  29. 05 11月, 2009 1 次提交
  30. 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
  31. 14 8月, 2009 1 次提交
    • J
      nl80211: add generation number to all dumps · f5ea9120
      Johannes Berg 提交于
      In order for userspace to be able to figure out whether
      it obtained a consistent snapshot of data or not when
      using netlink dumps, we need to have a generation number
      in each dump message that indicates whether the list has
      changed or not -- its value is arbitrary.
      
      This patch adds such a number to all dumps, this needs
      some mac80211 involvement to keep track of a generation
      number to start with when adding/removing mesh paths or
      stations.
      
      The wiphy and netdev lists can be fully handled within
      cfg80211, of course, but generation numbers need to be
      stored there as well.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f5ea9120