1. 30 Mar, 2015 7 commits
  2. 16 Mar, 2015 1 commit
  3. 04 Mar, 2015 2 commits
  4. 03 Mar, 2015 2 commits
    • Johannes Berg's avatar
      mac80211: fix another suspend vs. association race · be72afe0
      Johannes Berg authored
      Since cfg80211 disconnects, but has no insight into the association
      process, it can happen that it disconnects while association is in
      progress. We then try to abort association in mac80211, but this is
      only later so the association can complete between the two.
      This results in removing an interface from the driver while bound
      to the channel context, obviously causing confusion and issues.
      Solve this by also checking if we're associated during quiesce and
      if so deauthenticating. The frame will no longer go out to the AP
      which is a bit unfortunate, but it'll resolve the crash (and before
      we would have suspended without telling the AP as well.)
      I'm working on a better, but more complex solution as well, which
      should avoid that problem.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Alexander Bondar's avatar
      mac80211: Update beacon's timing and DTIM count on every beacon · 2ecc3905
      Alexander Bondar authored
      Beacon's timestamp, device system time associated with this beacon and
      DTIM count parameters are not updated in the associated vif context
      if the latest beacon's content is identical to the previously received.
      It make sense to update these changing parameters on every beacon so the
      driver can get most updated values. This may be necessary, for example,
      to avoid either beacons' drift effect or device time stamp overrun.
      IMPORTANT: Three sync_* parameters - sync_ts, sync_device_ts and
      sync_dtim_count would possibly be out of sync by the time the driver will
      use them. The synchronized view is currently guaranteed only in certain
      Signed-off-by: default avatarAlexander Bondar <alexander.bondar@intel.com>
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  5. 23 Jan, 2015 1 commit
    • Emmanuel Grumbach's avatar
      mac80211: synchronize_net() before flushing the queues · 14f2ae83
      Emmanuel Grumbach authored
      When mac80211 disconnects, it drops all the packets on the
      queues. This happens after the net stack has been notified
      that we have no link anymore (netif_carrier_off).
      netif_carrier_off ensures that no new packets are sent to
      xmit() callback, but we might have older packets in the
      middle of the Tx path. These packets will land in the
      driver's queues after the latter have been flushed.
      Synchronize_net() between netif_carrier_off and drv_flush()
      will fix this.
      Note that we can't call synchronize_net inside
      ieee80211_flush_queues since there are flows that call
      ieee80211_flush_queues and don't need synchronize_net()
      which is an expensive operation.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [reword comment to be more accurate]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  6. 19 Jan, 2015 1 commit
    • Emmanuel Grumbach's avatar
      mac80211: delete the assoc/auth timer upon suspend · c1e140bf
      Emmanuel Grumbach authored
      While suspending, we destroy the authentication /
      association that might be taking place. While doing so, we
      forgot to delete the timer which can be firing after
      local->suspended is already set, producing the warning below.
      Fix that by deleting the timer.
      [66722.825487] WARNING: CPU: 2 PID: 5612 at net/mac80211/util.c:755 ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]()
      [66722.825487] queueing ieee80211 work while going to suspend
      [66722.825529] CPU: 2 PID: 5612 Comm: kworker/u16:69 Tainted: G        W  O  3.16.1+ #24
      [66722.825537] Workqueue: events_unbound async_run_entry_fn
      [66722.825545] Call Trace:
      [66722.825552]  <IRQ>  [<ffffffff817edbb2>] dump_stack+0x4d/0x66
      [66722.825556]  [<ffffffff81075cad>] warn_slowpath_common+0x7d/0xa0
      [66722.825572]  [<ffffffffa06b5b90>] ? ieee80211_sta_bcn_mon_timer+0x50/0x50 [mac80211]
      [66722.825573]  [<ffffffff81075d1c>] warn_slowpath_fmt+0x4c/0x50
      [66722.825586]  [<ffffffffa06977a2>] ieee80211_can_queue_work.isra.18+0x32/0x40 [mac80211]
      [66722.825598]  [<ffffffffa06977d5>] ieee80211_queue_work+0x25/0x50 [mac80211]
      [66722.825611]  [<ffffffffa06b5bac>] ieee80211_sta_timer+0x1c/0x20 [mac80211]
      [66722.825614]  [<ffffffff8108655a>] call_timer_fn+0x8a/0x300
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  7. 14 Jan, 2015 1 commit
  8. 07 Jan, 2015 1 commit
  9. 17 Dec, 2014 3 commits
  10. 15 Dec, 2014 1 commit
  11. 12 Dec, 2014 1 commit
  12. 26 Nov, 2014 1 commit
  13. 24 Nov, 2014 1 commit
  14. 19 Nov, 2014 3 commits
  15. 10 Nov, 2014 2 commits
  16. 04 Nov, 2014 1 commit
    • Johannes Berg's avatar
      mac80211: handle RIC data element in reassociation request · 8ed28747
      Johannes Berg authored
      When the RIC data element (RDE) is included in the IEs coming
      from userspace for an association request, its handling is
      currently broken as any IEs that are contained within it would
      be split off from it and inserted again after all the IEs that
      mac80211 generates (e.g. HT, VHT.)
      To fix this, treat the RIC element specially, and stop after
      it only when we find something that doesn't actually belong to
      it. This assumes userspace is actually correctly building it,
      directly after the fast BSS transition IE and before all the
      others like extended capabilities.
      This leaves as a potential problem the case where userspace is
      building the following IEs:
      [RDE] [vendor resource description] [vendor non-resource IE]
      In this case, we'd erroneously consider all three IEs to be
      part of the RIC data together, and not split them between the
      two vendor IEs. Unfortunately, it isn't easily possible to
      distinguish vendor IEs, so this isn't easy to fix. Luckily,
      this case is rare as normally wpa_supplicant will include an
      extended capabilities IE in the IEs, and that certainly will
      break the two vendor IEs apart correctly.
      Reviewed-by: default avatarEliad Peller <eliad@wizery.com>
      Reviewed-by: default avatarBeni Lev <beni.lev@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  17. 29 Oct, 2014 2 commits
  18. 27 Oct, 2014 1 commit
  19. 22 Oct, 2014 1 commit
    • Johannes Berg's avatar
      mac80211: add WMM admission control support · 02219b3a
      Johannes Berg authored
      Use the currently existing APIs between mac80211 and the low
      level driver to implement WMM admission control.
      The low level driver needs to report the media time used by
      each transmitted packet in ieee80211_tx_status. Based on that
      information, mac80211 will modify the QoS parameters of the
      admission controlled Access Category when the limit is
      reached. Once the original QoS parameters can be restored,
      mac80211 will do so.
      One issue with this approach is that management frames will
      also erroneously be downgraded, but the upside is that the
      implementation is simple. In the future, it can be extended
      to driver- or device-based implementations that are better.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  20. 09 Oct, 2014 5 commits
  21. 11 Sep, 2014 2 commits