1. 05 9月, 2014 1 次提交
  2. 26 8月, 2014 3 次提交
    • J
      cfg80211: allow passing frame type to cfg80211_inform_bss() · 5bc8c1f2
      Johannes Berg 提交于
      When using the cfg80211_inform_bss[_width]() functions drivers
      cannot currently indicate whether the data was received in a
      beacon or probe response. Fix that by passing a new enum that
      indicates such (or unknown).
      
      For good measure, use it in ath6kl.
      
      Acked-by: Kalle Valo <kvalo@qca.qualcomm.com> [ath6kl]
      Acked-by: Arend van Spriel <arend@broadcom.com> [brcmfmac]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5bc8c1f2
    • J
      cfg80211: clarify BSS probe response vs. beacon data · 0e227084
      Johannes Berg 提交于
      There are a few possible cases of where BSS data came from:
       1) only a beacon has been received
       2) only a probe response has been received
       3) the driver didn't report what it received (this happens when
          using cfg80211_inform_bss[_width]())
       4) both probe response and beacon data has been received
      
      Unfortunately, in the userspace API, a few things weren't there:
       a) there was no way to differentiate cases 1) and 4) above
          without comparing the data of the IEs
       b) the TSF was always from the last frame, instead of being
          exposed for beacon/probe response separately like IEs
      
      Fix this by
         i) exporting a new flag attribute that indicates whether or
            not probe response data has been received - this addresses (a)
        ii) exporting a BEACON_TSF attribute that holds the beacon's TSF
            if a beacon has been received
       iii) not exporting the beacon attributes in case (3) above as that
            would just lead userspace into thinking the data actually came
            from a beacon when that isn't clear
      
      To implement this, track inside the IEs struct whether or not it
      (definitely) came from a beacon.
      
      Reported-by: William Seto
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      0e227084
    • V
      cfg80211: remove @gfp parameter from cfg80211_rx_mgmt() · 970fdfa8
      Vladimir Kondratiev 提交于
      In the cfg80211_rx_mgmt(), parameter @gfp was used for the memory allocation.
      But, memory get allocated under spin_lock_bh(), this implies atomic context.
      So, one can't use GFP_KERNEL, only variants with no __GFP_WAIT. Actually, in all
      occurrences GFP_ATOMIC is used (wil6210 use GFP_KERNEL by mistake),
      and it should be this way or warning triggered in the memory allocation code.
      
      Remove @gfp parameter as no actual choice exist, and use hard coded
      GFP_ATOMIC for memory allocation.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      970fdfa8
  3. 26 6月, 2014 1 次提交
  4. 23 6月, 2014 2 次提交
  5. 22 5月, 2014 1 次提交
    • E
      cfg80211: allow RSSI compensation · 67af9811
      Emmanuel Grumbach 提交于
      Channels in 2.4GHz band overlap, this means that if we
      send a probe request on channel 1 and then move to channel
      2, we will hear the probe response on channel 2. In this
      case, the RSSI will be lower than if we had heard it on
      the channel on which it was sent (1 in this case).
      
      The firmware / low level driver can parse the channel in
      the DS IE or HT IE and compensate the RSSI so that it will
      still have a valid value even if we heard the frame on an
      adjacent channel. This can be done up to a certain offset.
      
      Add this offset as a configuration for the low level driver.
      A low level driver that can compensate the low RSSI in this
      case should assign the maximal offset for which the RSSI
      value is still valid.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      67af9811
  6. 21 5月, 2014 1 次提交
  7. 20 5月, 2014 2 次提交
  8. 19 5月, 2014 3 次提交
  9. 15 5月, 2014 2 次提交
  10. 13 5月, 2014 1 次提交
  11. 09 5月, 2014 1 次提交
  12. 08 5月, 2014 1 次提交
  13. 06 5月, 2014 1 次提交
  14. 05 5月, 2014 1 次提交
  15. 29 4月, 2014 1 次提交
  16. 25 4月, 2014 2 次提交
  17. 09 4月, 2014 7 次提交
  18. 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
  19. 26 2月, 2014 2 次提交
  20. 21 2月, 2014 2 次提交
  21. 20 2月, 2014 2 次提交
  22. 05 2月, 2014 2 次提交
    • M
      cfg80211: consider existing DFS interfaces · 9e0e2961
      Michal Kazior 提交于
      It was possible to break interface combinations in
      the following way:
      
       combo 1: iftype = AP, num_ifaces = 2, num_chans = 2,
       combo 2: iftype = AP, num_ifaces = 1, num_chans = 1, radar = HT20
      
      With the above interface combinations it was
      possible to:
      
       step 1. start AP on DFS channel by matching combo 2
       step 2. start AP on non-DFS channel by matching combo 1
      
      This was possible beacuse (step 2) did not consider
      if other interfaces require radar detection.
      
      The patch changes how cfg80211 tracks channels -
      instead of channel itself now a complete chandef
      is stored.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9e0e2961
    • A
      cfg80211: fix channel configuration in IBSS join · fe94f3a4
      Antonio Quartulli 提交于
      When receiving an IBSS_JOINED event select the BSS object
      based on the {bssid, channel} couple rather than the bssid
      only.
      With the current approach if another cell having the same
      BSSID (but using a different channel) exists then cfg80211
      picks up the wrong BSS object.
      The result is a mismatching channel configuration between
      cfg80211 and the driver, that can lead to any sort of
      problem.
      
      The issue can be triggered by having an IBSS sitting on
      given channel and then asking the driver to create a new
      cell using the same BSSID but with a different frequency.
      By passing the channel to cfg80211_get_bss() we can solve
      this ambiguity and retrieve/create the correct BSS object.
      All the users of cfg80211_ibss_joined() have been changed
      accordingly.
      
      Moreover WARN when cfg80211_ibss_joined() gets a NULL
      channel as argument and remove a bogus call of the same
      function in ath6kl (it does not make sense to call
      cfg80211_ibss_joined() with a zero BSSID on ibss-leave).
      
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Arend van Spriel <arend@broadcom.com>
      Cc: Bing Zhao <bzhao@marvell.com>
      Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi>
      Cc: libertas-dev@lists.infradead.org
      Acked-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
      [minor code cleanup in ath6kl]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fe94f3a4