1. 21 10月, 2015 1 次提交
    • J
      mac80211: move station statistics into sub-structs · e5a9f8d0
      Johannes Berg 提交于
      Group station statistics by where they're (mostly) updated
      (TX, RX and TX-status) and group them into sub-structs of
      the struct sta_info.
      
      Also rename the variables since the grouping now makes it
      obvious where they belong.
      
      This makes it easier to identify where the statistics are
      updated in the code, and thus easier to think about them.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e5a9f8d0
  2. 13 10月, 2015 1 次提交
  3. 10 6月, 2015 1 次提交
  4. 11 5月, 2015 1 次提交
  5. 30 3月, 2015 3 次提交
  6. 20 3月, 2015 1 次提交
  7. 17 3月, 2015 1 次提交
  8. 04 3月, 2015 1 次提交
  9. 03 3月, 2015 1 次提交
    • D
      cfg80211: add bss_type and privacy arguments in cfg80211_get_bss() · 6eb18137
      Dedy Lansky 提交于
      802.11ad adds new a network type (PBSS) and changes the capability
      field interpretation for the DMG (60G) band.
      The same 2 bits that were interpreted as "ESS" and "IBSS" before are
      re-used as a 2-bit field with 3 valid values (and 1 reserved). Valid
      values are: "IBSS", "PBSS" (new) and "AP".
      
      In order to get the BSS struct for the new PBSS networks, change the
      cfg80211_get_bss() function to take a new enum ieee80211_bss_type
      argument with the valid network types, as "capa_mask" and "capa_val"
      no longer work correctly (the search must be band-aware now.)
      
      The remaining bits in "capa_mask" and "capa_val" are used only for
      privacy matching so replace those two with a privacy enum as well.
      Signed-off-by: NDedy Lansky <dlansky@codeaurora.org>
      [rewrite commit log, tiny fixes]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6eb18137
  10. 17 12月, 2014 1 次提交
  11. 29 10月, 2014 1 次提交
    • L
      mac80211: use secondary channel offset IE also beacons during CSA · 84469a45
      Luciano Coelho 提交于
      If we are switching from an HT40+ to an HT40- channel (or vice-versa),
      we need the secondary channel offset IE to specify what is the
      post-CSA offset to be used.  This applies both to beacons and to probe
      responses.
      
      In ieee80211_parse_ch_switch_ie() we were ignoring this IE from
      beacons and using the *current* HT information IE instead.  This was
      causing us to use the same offset as before the switch.
      
      Fix that by using the secondary channel offset IE also for beacons and
      don't ever use the pre-switch offset.  Additionally, remove the
      "beacon" argument from ieee80211_parse_ch_switch_ie(), since it's not
      needed anymore.
      
      Cc: stable@vger.kernel.org
      Reported-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      84469a45
  12. 05 9月, 2014 1 次提交
  13. 15 8月, 2014 1 次提交
  14. 21 7月, 2014 1 次提交
  15. 23 6月, 2014 1 次提交
  16. 27 5月, 2014 1 次提交
  17. 15 5月, 2014 1 次提交
  18. 09 4月, 2014 4 次提交
  19. 20 3月, 2014 1 次提交
    • E
      cfg80211/mac80211: ignore signal if the frame was heard on wrong channel · 3afc2167
      Emmanuel Grumbach 提交于
      On 2.4Ghz band, the channels overlap since the delta
      between different channels is 5Mhz while the width of the
      receiver is 20Mhz (at least).
      
      This means that we can hear beacons or probe responses from
      adjacent channels. These frames will have a significant
      lower RSSI which will feed all kinds of logic with inaccurate
      data. An obvious example is the roaming algorithm that will
      think our AP is getting weak and will try to move to another
      AP.
      
      In order to avoid this, update the signal only if the frame
      has been heard on the same channel as the one advertised by
      the AP in its DS / HT IEs.
      We refrain from updating the values only if the AP is
      already in the BSS list so that we will still have a valid
      (but inaccurate) value if the AP was heard on an adjacent
      channel only.
      
      To achieve this, stop taking the channel from DS / HT IEs
      in mac80211. The DS / HT IEs is taken into account to
      discard the frame if it was received on a disabled channel.
      This can happen due to the same phenomenon: the frame is
      sent on channel 12, but heard on channel 11 while channel
      12 can be disabled on certain devices. Since this check
      is done in cfg80211, stop even checking this in mac80211.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [remove unused rx_freq variable]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      3afc2167
  20. 21 2月, 2014 1 次提交
  21. 06 2月, 2014 1 次提交
    • S
      mac80211: Fix IBSS disconnect · d4c80d9d
      Sujith Manoharan 提交于
      Currently, when a station leaves an IBSS network, the
      corresponding BSS is not dropped from cfg80211 if there are
      other active stations in the network. But, the small
      window that is present when trying to determine a station's
      status based on IEEE80211_IBSS_MERGE_INTERVAL introduces
      a race.
      
      Instead of trying to keep the BSS, always remove it when
      leaving an IBSS network. There is not much benefit to retain
      the BSS entry since it will be added with a subsequent join
      operation.
      
      This fixes an issue where a dangling BSS entry causes ath9k
      to wait for a beacon indefinitely.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d4c80d9d
  22. 05 2月, 2014 8 次提交
  23. 19 12月, 2013 1 次提交
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
  24. 16 12月, 2013 3 次提交
  25. 06 12月, 2013 1 次提交
  26. 02 12月, 2013 1 次提交