| Message ID | 200909241055.51604.hs4233@mail.mn-solutions.de (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Thu, Sep 24, 2009 at 1:55 AM, Holger Schurig <hs4233@mail.mn-solutions.de> wrote: > Linux keeps scan results up to 15 seconds. This can be a problem for fast > moving client: they get back stale data. But if the kernel reports the > age of some BSS, then user-space can simply weed out old entries. > > Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de> > > --- > > One question was if I should specify the age in ms, or if I should specify > an absolute time. In the end I thought age in ms is better suited. > > If an absolute time would sent with every BSS item, then user-space would > need an additional call to time() to find out which BSS items are too old. > Now it can use the milliseconds directly. > > The case there user-space wants an absolute time ("At what hour did I get > the last probe response from this AP?") seems to be a more theoretical > problem. But if info is wanted, *THEN* you can call time() and substract the > reported bss-item-age from it. > > > Index: linux-wl/include/linux/nl80211.h > =================================================================== > --- linux-wl.orig/include/linux/nl80211.h    2009-09-24 09:19:03.000000000 +0200 > +++ linux-wl/include/linux/nl80211.h   2009-09-24 09:19:42.000000000 +0200 > @@ -1277,6 +1277,7 @@ enum nl80211_channel_type { >  * @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon >  *   in unspecified units, scaled to 0..100 (u8) >  * @NL80211_BSS_STATUS: status, if this BSS is "used" > + * @NL80211_BSS_AGE_MS: age of this BSS entry in ms >  * @__NL80211_BSS_AFTER_LAST: internal >  * @NL80211_BSS_MAX: highest BSS attribute >  */ > @@ -1291,6 +1292,7 @@ enum nl80211_bss { >     NL80211_BSS_SIGNAL_MBM, >     NL80211_BSS_SIGNAL_UNSPEC, >     NL80211_BSS_STATUS, > +    NL80211_BSS_AGE_MS, Wil want to #define NL80211_BSS_AGE_MS NL80211_BSS_AGE_MS as well so userspace apps can ifdef around that feature to know if its supported. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 24 September 2009 10:59:57 Luis R. Rodriguez wrote: > Wil want to #define NL80211_BSS_AGE_MS NL80211_BSS_AGE_MS as > well so userspace apps can ifdef around that feature to know if > its supported. Nice idea. That could be a different patch. I haven't seen it for anything else, e.g. there's no "#define NL80211_BSS_STATUS" anywhere. "iw" for example has it's own nl80211.h file.
On Thu, Sep 24, 2009 at 2:19 AM, Holger Schurig <hs4233@mail.mn-solutions.de> wrote: > On Thursday 24 September 2009 10:59:57 Luis R. Rodriguez wrote: >> Wil want to #define NL80211_BSS_AGE_MS NL80211_BSS_AGE_MS as >> well so userspace apps can ifdef around that feature to know if >> its supported. > > Nice idea. > > That could be a different patch. I haven't seen it for anything > else, e.g. there's no "#define NL80211_BSS_STATUS" anywhere. Typically a command went in with a set of attributes, I tend to only add a define for a new command, and then for any new attributes after that in later patches for the same command. > "iw" for example has it's own nl80211.h file. Yes, but not all apps may ship their own ni80211.h, we probably will be implementing then, but yeah -- we cannot enforce this, only recommend it. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2009-09-24 at 10:55 +0200, Holger Schurig wrote:
> + * @NL80211_BSS_AGE_MS: age of this BSS entry in ms
I'm not sure "age" is appropriate -- the BSS entry might be older but
have been touched in a new scan etc.
Maybe "last seen"? Although that kinda implies an absolute time while
"age" implies a relative time ... hmm ...
johannes
> I'm not sure "age" is appropriate -- the BSS entry might be older but > have been touched in a new scan etc. > > Maybe "last seen"? Although that kinda implies an absolute time while > "age" implies a relative time ... hmm ... NL80211_BSS_SEEN_MS_AGO ?
On Thu, Sep 24, 2009 at 10:55:51AM +0200, Holger Schurig wrote: > One question was if I should specify the age in ms, or if I should specify > an absolute time. In the end I thought age in ms is better suited. > > If an absolute time would sent with every BSS item, then user-space would > need an additional call to time() to find out which BSS items are too old. > Now it can use the milliseconds directly. This would depend on your use case.. I would have preferred absolute time since it allows the application to filter out entries that were not updated after the last scan request, i.e., to figure out which entries were found based on the last scan request (or well, based on frames received during this time). > The case there user-space wants an absolute time ("At what hour did I get > the last probe response from this AP?") seems to be a more theoretical > problem. But if info is wanted, *THEN* you can call time() and substract the > reported bss-item-age from it. No you cannot or well, you cannot get the exact time using this mechanism since you do not know the exact time used in the kernel for calculating the age. Anyway, the exact time may not matter that much if there were a better way at figuring out whether the results are based on a specific scan request. One option would be to add a sequence number into scan requests and report this to the user space in the scan completed event. The scan results would also need to include the sequence number of the scan request after which they were updated.
On Saturday 26 September 2009 10:14:38 Jouni Malinen wrote: > This would depend on your use case.. I would have preferred > absolute time since it allows the application to filter out > entries that were not updated after the last scan request, > i.e., to figure out which entries were found based on the last > scan request (or well, based on frames received during this > time). Oh, we can still easily change that to an absolute time, if you prefer. It's not yet upstream, AFAIK. With the current patch, I'll still ignore scan results with an age > 3 seconds. To make a decision about "which AP should I use next", I don't need to know if the result was from this scan request, or from the one before, or from a shell script doing while true; do iw xxx scan trigger freq 2412 essid SOME_AP sleep 0.5 done
Index: linux-wl/include/linux/nl80211.h =================================================================== --- linux-wl.orig/include/linux/nl80211.h 2009-09-24 09:19:03.000000000 +0200 +++ linux-wl/include/linux/nl80211.h 2009-09-24 09:19:42.000000000 +0200 @@ -1277,6 +1277,7 @@ enum nl80211_channel_type { * @NL80211_BSS_SIGNAL_UNSPEC: signal strength of the probe response/beacon * in unspecified units, scaled to 0..100 (u8) * @NL80211_BSS_STATUS: status, if this BSS is "used" + * @NL80211_BSS_AGE_MS: age of this BSS entry in ms * @__NL80211_BSS_AFTER_LAST: internal * @NL80211_BSS_MAX: highest BSS attribute */ @@ -1291,6 +1292,7 @@ enum nl80211_bss { NL80211_BSS_SIGNAL_MBM, NL80211_BSS_SIGNAL_UNSPEC, NL80211_BSS_STATUS, + NL80211_BSS_AGE_MS, /* keep last */ __NL80211_BSS_AFTER_LAST, Index: linux-wl/net/wireless/nl80211.c =================================================================== --- linux-wl.orig/net/wireless/nl80211.c 2009-09-24 09:19:03.000000000 +0200 +++ linux-wl/net/wireless/nl80211.c 2009-09-24 09:37:40.000000000 +0200 @@ -3105,6 +3105,7 @@ static int nl80211_send_bss(struct sk_bu NLA_PUT_U16(msg, NL80211_BSS_BEACON_INTERVAL, res->beacon_interval); NLA_PUT_U16(msg, NL80211_BSS_CAPABILITY, res->capability); NLA_PUT_U32(msg, NL80211_BSS_FREQUENCY, res->channel->center_freq); + NLA_PUT_U32(msg, NL80211_BSS_AGE_MS, jiffies_to_msecs(jiffies - intbss->ts)); switch (rdev->wiphy.signal_type) { case CFG80211_SIGNAL_TYPE_MBM:
Linux keeps scan results up to 15 seconds. This can be a problem for fast moving client: they get back stale data. But if the kernel reports the age of some BSS, then user-space can simply weed out old entries. Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de> --- One question was if I should specify the age in ms, or if I should specify an absolute time. In the end I thought age in ms is better suited. If an absolute time would sent with every BSS item, then user-space would need an additional call to time() to find out which BSS items are too old. Now it can use the milliseconds directly. The case there user-space wants an absolute time ("At what hour did I get the last probe response from this AP?") seems to be a more theoretical problem. But if info is wanted, *THEN* you can call time() and substract the reported bss-item-age from it.