summaryrefslogtreecommitdiff
path: root/net/mac80211
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2014-08-12 22:34:30 +0400
committerJohannes Berg <johannes.berg@intel.com>2014-08-26 13:16:01 +0400
commit0e227084aee36b3ba27b4fc9cd9e425be6ce2ab8 (patch)
tree5a862e85d25ad5cf05e8f47800e20de792592e91 /net/mac80211
parentf41ef64853fb1e02728e56b2d0d55aef8ed12b26 (diff)
downloadlinux-0e227084aee36b3ba27b4fc9cd9e425be6ce2ab8.tar.xz
cfg80211: clarify BSS probe response vs. beacon data
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: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'net/mac80211')
0 files changed, 0 insertions, 0 deletions