1. 19 11月, 2009 4 次提交
  2. 14 11月, 2009 1 次提交
  3. 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
  4. 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
  5. 03 11月, 2009 1 次提交
  6. 31 10月, 2009 4 次提交
  7. 28 10月, 2009 1 次提交
  8. 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
  9. 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
  10. 01 9月, 2009 1 次提交
  11. 14 8月, 2009 6 次提交
  12. 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
  13. 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
  14. 28 7月, 2009 5 次提交
  15. 25 7月, 2009 4 次提交
  16. 22 7月, 2009 1 次提交
  17. 06 7月, 2009 1 次提交
  18. 13 6月, 2009 1 次提交
  19. 11 6月, 2009 3 次提交
  20. 04 6月, 2009 1 次提交