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 <[email protected]>
---
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,
/* 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:
--
http://www.holgerschurig.de
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
--
http://www.holgerschurig.de
On Thu, Sep 24, 2009 at 2:19 AM, Holger Schurig
<[email protected]> 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
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.
--
http://www.holgerschurig.de
> 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 ?
--
http://www.holgerschurig.de
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
On Mon, Sep 28, 2009 at 09:14:48AM +0200, Holger Schurig wrote:
> Oh, we can still easily change that to an absolute time, if you
> prefer. It's not yet upstream, AFAIK.
I have had hard time trying to figure out which option I would really
prefer.. ;-) Since the patch is actually in wireless-testing.git now and
I do not have that strong opinion either way, it's fine to leave it in
as-is. If anyone gets interested enough in trying to figure out whether
scan results are from the time after the last scan (more exactly than
just guessing based on age), he/she can add that later and probably
using something like a sequence number for scan requests, etc.
--
Jouni Malinen PGP id EFC895FA
On Thu, Sep 24, 2009 at 1:55 AM, Holger Schurig
<[email protected]> 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 <[email protected]>
>
> ---
>
> 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
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.
--
Jouni Malinen PGP id EFC895FA
> If anyone gets interested enough in trying to figure out whether
> scan results are from the time after the last scan (more exactly than
> just guessing based on age), he/she can add that later and probably
> using something like a sequence number for scan requests, etc.
Hmm, what would a scan-sequence help in the case when mac80211 updates
a BSS because of a received beacon?
E.g.:
scan trigger, seq 5:
find AP 'XXX', signal -50
find AP 'YYY', signal -60
scan trigger, seq 6:
find AP 'ZZZ', signal -55
normal operation:
beacon for 'YYY' comes in, signal -45
scan-dump:
get 'XXX', signal -50, seq 5
get 'ZZZ', signal -55, seq 6
get 'YYY', signal -45, but with which seq?
--
http://www.holgerschurig.de
On Thu, Oct 01, 2009 at 09:57:31AM +0200, Holger Schurig wrote:
> Hmm, what would a scan-sequence help in the case when mac80211 updates
> a BSS because of a received beacon?
I have been most interested in knowing whether the result was after the
scan request or not; not necessarily receiving during the scan request
itself.
> scan trigger, seq 5:
> find AP 'XXX', signal -50
> find AP 'YYY', signal -60
> scan trigger, seq 6:
> find AP 'ZZZ', signal -55
> normal operation:
> beacon for 'YYY' comes in, signal -45
> scan-dump:
> get 'XXX', signal -50, seq 5
> get 'ZZZ', signal -55, seq 6
> get 'YYY', signal -45, but with which seq?
seq 6 based on the earlier discussion. However, there would be an option
to increment the sequence number whenever a scan is terminated, i.e.,
the move to normal operation would move to seq 7 and 'YYY' would
actually show up with seq 7 here. The scan trigger command would return
the sequence number for that particular scan (6 for the second one), so
it would be possible to notice the difference between ZZZ and YYY.
--
Jouni Malinen PGP id EFC895FA