On Thu, Aug 14, 2014 at 2:07 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > From: Johannes Berg <johannes.berg@xxxxxxxxx> > > 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@xxxxxxxxx> > --- looks good. > @@ -982,11 +983,12 @@ cfg80211_inform_bss_width_frame(struct wiphy *wiphy, > + ies->from_beacon = !ieee80211_is_probe_resp(mgmt->frame_control); it's basically the same, but i think ieee80211_is_beacon() is a bit more straight-forward :) Eliad. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
