1. 01 3月, 2015 1 次提交
    • J
      mac80211: remove TX latency measurement code · abfbc3af
      Johannes Berg 提交于
      Revert commit ad38bfc9 ("mac80211: Tx frame latency statistics")
      (along with some follow-up fixes).
      
      This code turned out not to be as useful in the current form as we
      thought, and we've internally hacked it up more, but that's not
      very suitable for upstream (for now), and we might just do that
      with tracing instead.
      
      Therefore, for now at least, remove this code. We might also need
      to use the skb->tstamp field for the TCP performance issue, which
      is more important than the debugging.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      abfbc3af
  2. 08 1月, 2015 1 次提交
  3. 20 11月, 2014 3 次提交
  4. 09 10月, 2014 1 次提交
  5. 11 9月, 2014 1 次提交
  6. 05 9月, 2014 1 次提交
  7. 03 9月, 2014 1 次提交
    • M
      mac80211: fix offloaded BA session traffic after hw restart · 4549cf2b
      Michal Kazior 提交于
      When starting an offloaded BA session it is
      unknown what starting sequence number should be
      used. Using last_seq worked in most cases except
      after hw restart.
      
      When hw restart is requested last_seq is
      (rightfully so) kept unmodified. This ended up
      with BA sessions being restarted with an aribtrary
      BA window values resulting in dropped frames until
      sequence numbers caught up.
      
      Instead of last_seq pick seqno of a first Rxed
      frame of a given BA session.
      
      This fixes stalled traffic after hw restart with
      offloaded BA sessions (currently only ath10k).
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4549cf2b
  8. 15 8月, 2014 1 次提交
  9. 21 7月, 2014 2 次提交
  10. 23 6月, 2014 4 次提交
    • J
      cfg80211: make ethtool the driver's responsibility · b7ffbd7e
      Johannes Berg 提交于
      Currently, cfg80211 tries to implement ethtool, but that doesn't
      really scale well, with all the different operations. Make the
      lower-level driver responsible for it, which currently only has
      an effect on mac80211. It will similarly not scale well at that
      level though, since mac80211 also has many drivers.
      
      To cleanly implement this in mac80211, introduce a new file and
      move some code to appropriate places.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b7ffbd7e
    • J
      mac80211: remove weak WEP IV accounting · ba9030c2
      Johannes Berg 提交于
      Since WEP is practically dead, there seems very little
      point in keeping WEP weak IV accounting.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ba9030c2
    • B
      mac80211: remove ignore_plink_timer flag · 2b470c39
      Bob Copeland 提交于
      The mesh_plink code is doing some interesting things with the
      ignore_plink_timer flag.  It seems the original intent was to
      handle this race:
      
      cpu 0                           cpu 1
      -----                           -----
                                      start timer handler for state X
      acquire sta_lock
      change state from X to Y
      mod_timer() / del_timer()
      release sta_lock
                                      acquire sta_lock
                                      execute state Y timer too soon
      
      However, using the mod_timer()/del_timer() return values to
      detect these cases is broken.  As a result, timers get ignored
      unnecessarily, and stations can get stuck in the peering state
      machine.
      
      Instead, we can detect the case by looking at the timer expiration.
      In the case of del_timer, just ignore the timers in the following
      (LISTEN/ESTAB) states since they won't have timers anyway.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2b470c39
    • J
      mac80211: fix station/driver powersave race · 5ac2e350
      Johannes Berg 提交于
      It is currently possible to have a race due to the station PS
      unblock work like this:
       * station goes to sleep with frames buffered in the driver
       * driver blocks wakeup
       * station wakes up again
       * driver flushes/returns frames, and unblocks, which schedules
         the unblock work
       * unblock work starts to run, and checks that the station is
         awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
       * we process a received frame with PM=1, setting the flag again
       * ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
         to the driver, and then clearing the WLAN_STA_PS_DRIVER and
         WLAN_STA_PS_STA flags
      
      In this scenario, mac80211 will think that the station is awake,
      while it really is asleep, and any TX'ed frames should be filtered
      by the device (it will know that the station is sleeping) but then
      passed to mac80211 again, which will not buffer it either as it
      thinks the station is awake, and eventually the packets will be
      dropped.
      
      Fix this by moving the clearing of the flags to exactly where we
      learn about the situation. This creates a problem of reordering,
      so introduce another flag indicating that delivery is being done,
      this new flag also queues frames and is cleared only while the
      spinlock is held (which the queuing code also holds) so that any
      concurrent delivery/TX is handled correctly.
      Reported-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5ac2e350
  11. 20 2月, 2014 1 次提交
    • E
      mac80211: fix AP powersave TX vs. wakeup race · 1d147bfa
      Emmanuel Grumbach 提交于
      There is a race between the TX path and the STA wakeup: while
      a station is sleeping, mac80211 buffers frames until it wakes
      up, then the frames are transmitted. However, the RX and TX
      path are concurrent, so the packet indicating wakeup can be
      processed while a packet is being transmitted.
      
      This can lead to a situation where the buffered frames list
      is emptied on the one side, while a frame is being added on
      the other side, as the station is still seen as sleeping in
      the TX path.
      
      As a result, the newly added frame will not be send anytime
      soon. It might be sent much later (and out of order) when the
      station goes to sleep and wakes up the next time.
      
      Additionally, it can lead to the crash below.
      
      Fix all this by synchronising both paths with a new lock.
      Both path are not fastpath since they handle PS situations.
      
      In a later patch we'll remove the extra skb queue locks to
      reduce locking overhead.
      
      BUG: unable to handle kernel
      NULL pointer dereference at 000000b0
      IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
      EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
      ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
      Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
      iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
      Stack:
       e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
       ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
       ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
      Call Trace:
       [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
       [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
       [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
       [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
       [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
       [<c149ef70>] dev_hard_start_xmit+0x450/0x950
       [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
       [<c14b9c9b>] __qdisc_run+0x4b/0x150
       [<c149f732>] dev_queue_xmit+0x2c2/0xca0
      
      Cc: stable@vger.kernel.org
      Reported-by: NYaara Rozenblum <yaara.rozenblum@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NStanislaw Gruszka <sgruszka@redhat.com>
      [reword commit log, use a separate lock]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d147bfa
  12. 06 2月, 2014 1 次提交
  13. 16 12月, 2013 3 次提交
  14. 02 12月, 2013 1 次提交
  15. 26 11月, 2013 2 次提交
  16. 28 10月, 2013 1 次提交
    • E
      mac80211: implement SMPS for AP · 687da132
      Emmanuel Grumbach 提交于
      When the driver requests to move to STATIC or DYNAMIC SMPS,
      we send an action frame to each associated station and
      reconfigure the channel context / driver.
      Of course, non-MIMO stations are ignored.
      
      The beacon isn't updated. The association response will
      include the original capabilities. Stations that associate
      while in non-OFF SMPS mode will get an action frame right
      after association to inform them about our current state.
      Note that we wait until the end of the EAPOL. Sending an
      action frame before the EAPOL is finished can be an issue
      for a few clients. Clients aren't likely to send EAPOL
      frames in MIMO anyway.
      
      When the SMPS configuration gets more permissive (e.g.
      STATIC -> OFF), we don't wake up stations that are asleep
      We remember that they don't know about the change and send
      the action frame when they wake up.
      
      When the SMPS configuration gets more restrictive (e.g.
      OFF -> STATIC), we set the TIM bit for every sleeping STA.
      uAPSD stations might send MIMO until they poll the action
      frame, but this is for a short period of time.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [fix vht streams loop, initialisation]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      687da132
  17. 13 6月, 2013 1 次提交
  18. 05 6月, 2013 1 次提交
  19. 17 5月, 2013 1 次提交
  20. 07 3月, 2013 1 次提交
  21. 06 3月, 2013 1 次提交
  22. 18 2月, 2013 1 次提交
  23. 15 2月, 2013 2 次提交
    • J
      mac80211: handle VHT operating mode notification · 0af83d3d
      Johannes Berg 提交于
      Handle the operating mode notification action frame.
      When the supported streams or the bandwidth change
      let the driver and rate control algorithm know.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0af83d3d
    • J
      mac80211: stop toggling IEEE80211_HT_CAP_SUP_WIDTH_20_40 · e1a0c6b3
      Johannes Berg 提交于
      For VHT, many more bandwidth changes are possible. As a first
      step, stop toggling the IEEE80211_HT_CAP_SUP_WIDTH_20_40 flag
      in the HT capabilities and instead introduce a bandwidth field
      indicating the currently usable bandwidth to transmit to the
      station. Of course, make all drivers use it.
      
      To achieve this, make ieee80211_ht_cap_ie_to_sta_ht_cap() get
      the station as an argument, rather than the new capabilities,
      so it can set up the new bandwidth field.
      
      If the station is a VHT station and VHT bandwidth is in use,
      also set the bandwidth accordingly.
      
      Doing this allows us to get rid of the supports_40mhz flag as
      the HT capabilities now reflect the true capability instead of
      the current setting.
      
      While at it, also fix ieee80211_ht_cap_ie_to_sta_ht_cap() to not
      ignore HT cap overrides when MCS TX isn't supported (not that it
      really happens...)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e1a0c6b3
  24. 12 2月, 2013 1 次提交
  25. 05 2月, 2013 1 次提交
    • M
      mac80211: mesh power save basics · 3f52b7e3
      Marco Porsch 提交于
      Add routines to
      - maintain a PS mode for each peer and a non-peer PS mode
      - indicate own PS mode in transmitted frames
      - track neighbor STAs power modes
      - buffer frames when neighbors are in PS mode
      - add TIM and Awake Window IE to beacons
      - release frames in Mesh Peer Service Periods
      
      Add local_pm to sta_info to represent the link-specific power
      mode at this station towards the remote station. When a peer
      link is established, use the default power mode stored in mesh
      config. Update the PS status if the peering status of a neighbor
      changes.
      Maintain a mesh power mode for non-peer mesh STAs. Set the
      non-peer power mode to active mode during peering. Authenticated
      mesh peering is currently not working when either node is
      configured to be in power save mode.
      
      Indicate the current power mode in transmitted frames. Use QoS
      Nulls to indicate mesh power mode transitions.
      For performance reasons, calls to the function setting the frame
      flags are placed in HWMP routing routines, as there the STA
      pointer is already available.
      
      Add peer_pm to sta_info to represent the peer's link-specific
      power mode towards the local station. Add nonpeer_pm to
      represent the peer's power mode towards all non-peer stations.
      Track power modes based on received frames.
      
      Add the ps_data structure to ieee80211_if_mesh (for TIM map, PS
      neighbor counter and group-addressed frame buffer).
      
      Set WLAN_STA_PS flag for STA in PS mode to use the unicast frame
      buffering routines in the tx path. Update num_sta_ps to buffer
      and release group-addressed frames after DTIM beacons.
      
      Announce the awake window duration in beacons if in light or
      deep sleep mode towards any peer or non-peer. Create a TIM IE
      similarly to AP mode and add it to mesh beacons. Parse received
      Awake Window IEs and check TIM IEs for buffered frames.
      
      Release frames towards peers in mesh Peer Service Periods. Use
      the corresponding trigger frames and monitor the MPSP status.
      Append a QoS Null as trigger frame if neccessary to properly end
      the MPSP. Currently, in HT channels MPSPs behave imperfectly and
      show large delay spikes and frame losses.
      Signed-off-by: NMarco Porsch <marco@cozybit.com>
      Signed-off-by: NIvan Bezyazychnyy <ivan.bezyazychnyy@gmail.com>
      Signed-off-by: NMike Krinkin <krinkin.m.u@gmail.com>
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3f52b7e3
  26. 03 1月, 2013 5 次提交