1. 26 8月, 2014 2 次提交
    • 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
  2. 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
  3. 05 5月, 2014 1 次提交
  4. 25 4月, 2014 2 次提交
  5. 10 4月, 2014 2 次提交
  6. 20 3月, 2014 2 次提交
    • Z
      cfg80211: remove unnecessary check · 4da64622
      Zhao, Gang 提交于
      RCU pointer bss->pub.beacon_ies is checked before in previous
      statement:
      
      if (rcu_access_pointer(bss->pub.beacon_ies))
      	continue;
      
      There is no need to check it twice(and in the wrong way :) ).
      Signed-off-by: NZhao, Gang <gamerh2o@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4da64622
    • 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
  7. 06 2月, 2014 1 次提交
    • J
      cfg80211: send scan results from work queue · f9d15d16
      Johannes Berg 提交于
      Due to the previous commit, when a scan finishes, it is in theory
      possible to hit the following sequence:
       1. interface starts being removed
       2. scan is cancelled by driver and cfg80211 is notified
       3. scan done work is scheduled
       4. interface is removed completely, rdev->scan_req is freed,
          event sent to userspace but scan done work remains pending
       5. new scan is requested on another virtual interface
       6. scan done work runs, freeing the still-running scan
      
      To fix this situation, hang on to the scan done message and block
      new scans while that is the case, and only send the message from
      the work function, regardless of whether the scan_req is already
      freed from interface removal. This makes step 5 above impossible
      and changes step 6 to be
       5. scan done work runs, sending the scan done message
      
      As this can't work for wext, so we send the message immediately,
      but this shouldn't be an issue since we still return -EBUSY.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9d15d16
  8. 09 1月, 2014 1 次提交
  9. 06 12月, 2013 1 次提交
    • E
      cfg80211: don't "leak" uncompleted scans · 4a58e7c3
      Eliad Peller 提交于
      ___cfg80211_scan_done() can be called in some cases
      (e.g. on NETDEV_DOWN) before the low level driver
      notified scan completion (which is indicated by
      passing leak=true).
      
      Clearing rdev->scan_req in this case is buggy, as
      scan_done_wk might have already being queued/running
      (and can't be flushed as it takes rtnl()).
      
      If a new scan will be requested at this stage, the
      scan_done_wk will try freeing it (instead of the
      previous scan), and this will later result in
      a use after free.
      
      Simply remove the "leak" option, and replace it with
      a standard WARN_ON.
      
      An example backtrace after such crash:
      Unable to handle kernel paging request at virtual address fffffee5
      pgd = c0004000
      [fffffee5] *pgd=9fdf6821, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] SMP ARM
      PC is at cfg80211_scan_done+0x28/0xc4 [cfg80211]
      LR is at __ieee80211_scan_completed+0xe4/0x2dc [mac80211]
      [<bf0077b0>] (cfg80211_scan_done+0x28/0xc4 [cfg80211])
      [<bf0973d4>] (__ieee80211_scan_completed+0xe4/0x2dc [mac80211])
      [<bf0982cc>] (ieee80211_scan_work+0x94/0x4f0 [mac80211])
      [<c005fd10>] (process_one_work+0x1b0/0x4a8)
      [<c0060404>] (worker_thread+0x138/0x37c)
      [<c0066d70>] (kthread+0xa4/0xb0)
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4a58e7c3
  10. 21 10月, 2013 1 次提交
  11. 04 9月, 2013 1 次提交
  12. 16 7月, 2013 1 次提交
  13. 24 6月, 2013 1 次提交
  14. 25 5月, 2013 2 次提交
  15. 24 3月, 2013 1 次提交
    • J
      cfg80211: always check for scan end on P2P device · f9f47529
      Johannes Berg 提交于
      If a P2P device wdev is removed while it has a scan, then the
      scan completion might crash later as it is already freed by
      that time. To avoid the crash always check the scan completion
      when the P2P device is being removed for some reason. If the
      driver already canceled it, don't want and free it, otherwise
      warn and leak it to avoid later crashes.
      
      In order to do this, locking needs to be changed away from the
      rdev mutex (which can't always be guaranteed). For now, use
      the sched_scan_mtx instead, I'll rename it to just scan_mtx in
      a later patch.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f9f47529
  16. 07 3月, 2013 1 次提交
    • J
      cfg80211: fix potential BSS memory leak and update · 1345ee6a
      Johannes Berg 提交于
      In the odd case that while updating information from a beacon,
      a BSS was found that is part of a hidden group, we drop the
      new information. In this case, however, we leak the IE buffer
      from the update, and erroneously update the entry's timestamp
      so it will never time out. Fix both these issues.
      
      Cc: Larry Finger <Larry.Finger@lwfinger.net>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1345ee6a
  17. 15 2月, 2013 1 次提交
  18. 13 2月, 2013 1 次提交
  19. 12 2月, 2013 4 次提交
    • J
      cfg80211: move TSF into IEs · 8cef2c9d
      Johannes Berg 提交于
      While technically the TSF isn't an IE, it can be
      necessary to distinguish between the TSF from a
      beacon and a probe response, in particular in
      order to know the next DTIM TBTT, as not all APs
      are spec compliant wrt. TSF==0 being a DTIM TBTT
      and thus the DTIM count needs to be taken into
      account as well.
      
      To allow this, move the TSF into the IE struct
      so it can be known whence it came.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8cef2c9d
    • J
      cfg80211: remove scan ies NULL check · 83c7aa1a
      Johannes Berg 提交于
      There's no way scan BSS IEs can be NULL as even
      if the allocation fails the frame is discarded.
      Remove some code checking for this and document
      that it is always non-NULL.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      83c7aa1a
    • J
      cfg80211: track hidden SSID networks properly · 776b3580
      Johannes Berg 提交于
      Currently, cfg80211 will copy beacon IEs from a previously
      received hidden SSID beacon to a probe response entry, if
      that entry is created after the beacon entry. However, if
      it is the other way around, or if the beacon is updated,
      such changes aren't propagated.
      
      Fix this by tracking the relation between the probe
      response and beacon BSS structs in this case.
      
      In case drivers have private data stored in a BSS struct
      and need access to such data from a beacon entry, cfg80211
      now provides the hidden_beacon_bss pointer from the probe
      response entry to the beacon entry.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      776b3580
    • J
      cfg80211: pass wiphy to cfg80211_ref_bss/put_bss · 5b112d3d
      Johannes Berg 提交于
      This prepares for using the spinlock instead of krefs
      which is needed in the next patch to track the refs
      of combined BSSes correctly.
      
      Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5b112d3d
  20. 05 2月, 2013 9 次提交
  21. 31 1月, 2013 1 次提交
  22. 24 1月, 2013 1 次提交
  23. 30 11月, 2012 2 次提交
    • J
      cfg80211: fix BSS struct IE access races · 9caf0364
      Johannes Berg 提交于
      When a BSS struct is updated, the IEs are currently
      overwritten or freed. This can lead to races if some
      other CPU is accessing the BSS struct and using the
      IEs concurrently.
      
      Fix this by always allocating the IEs in a new struct
      that holds the data and length and protecting access
      to this new struct with RCU.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9caf0364
    • J
      cfg80211: fix cmp_hidden_bss · f94f8b16
      Johannes Berg 提交于
      The cmp_bss() comparator function uses memcmp() to
      compare the SSID. This means that cmp_hidden_bss()
      needs to similarly return a number bigger than zero
      (use 1) instead of -1 when ie1 is bigger than ie2,
      which is the case if an ie2 byte is non-zero.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f94f8b16