[ath9k-devel] ath9k: signal level of rxed probe req.

[ath9k-devel] ath9k: signal level of rxed probe req.

[Lukasz]

Hi,

I'm trying to use ath9k (on AP side) to estimate distance between wifi-enabled 
device and AP basing on signal level of probe requests. I'm not expecting to 
achieve great accuracy, just want to be able to tell whether device is close, in 
middle range or far away from AP.

I'm using Linux OpenWrt 3.2.14 with compat-wireless-2012-02-27 snapshot. It's 
running on TL-WR941ND AP (SoC: Atheros AR9132 rev 2, phy0: Atheros AR9100 MAC/BB 
Rev:7 AR2133 RF Rev:a2 mem=0xb80c0000, irq=2).

I'm observing following behaviour (I don't have good radio background, so please 
correct me if I'm wrong):
it seems that device (eg. sony xperia x10 with Android and TI wlan chip; other 
devices behave in similar way) is sending probe requests on different channels. 
If my AP is configured on channel 11, it will also receive probe requests sent 
on channel 10, but with lower signal level.

E.g., with such ath9k code modification:

diff --git a/ath9k/recv.c b/ath9k/recv.c
index 5c40a8f..143c6e7 100644
--- a/ath9k/recv.c
+++ b/ath9k/recv.c
@@ -1877,6 +1877,14 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp)
                         goto requeue_drop_frag;


+               if (ieee80211_is_probe_req(hdr->frame_control) &&
+                   rxs->signal) {
+                       printk(KERN_DEBUG "%pM rssi: %.2d, ctl: %.2d:%.2d:%.2d"
+                              ", ext: %d:%d:%d\n", hdr->addr2, rs.rs_rssi,
+                              rs.rs_rssi_ctl[0], rs.rs_rssi_ctl[1],
+                              rs.rs_rssi_ctl[2], rs.rs_rssi_ext[0],
+                              rs.rs_rssi_ext[1], rs.rs_rssi_ext[2]);
+               }
                 /* Ensure we always have an skb to requeue once we are done
                  * processing the current buffer's skb */
                 requeue_skb = ath_rxbuf_alloc(common, common->rx_bufsize, 
GFP_ATOMIC);

I can observe following output:

[  958.190000] 6c:23:b9:7f:4f:02 rssi: 17, ctl: 03:17:02, ext: -128:-128:-128
[  958.610000] 6c:23:b9:7f:4f:02 rssi: 19, ctl: 11:19:05, ext: -128:-128:-128
[  958.650000] 6c:23:b9:7f:4f:02 rssi: 20, ctl: 10:20:03, ext: -128:-128:-128
[  958.870000] 6c:23:b9:7f:4f:02 rssi: 22, ctl: 13:21:08, ext: -128:-128:-128
[  959.170000] 6c:23:b9:7f:4f:02 rssi: 63, ctl: 55:62:49, ext: -128:-128:-128
[  959.190000] 6c:23:b9:7f:4f:02 rssi: 63, ctl: 56:62:49, ext: -128:-128:-128
[  959.210000] 6c:23:b9:7f:4f:02 rssi: 62, ctl: 53:61:50, ext: -128:-128:-128
[  959.280000] 6c:23:b9:7f:4f:02 rssi: 64, ctl: 56:63:48, ext: -128:-128:-128
[  959.300000] 6c:23:b9:7f:4f:02 rssi: 63, ctl: 55:62:48, ext: -128:-128:-128
[  959.320000] 6c:23:b9:7f:4f:02 rssi: 63, ctl: 54:62:49, ext: -128:-128:-128
[  964.400000] 6c:23:b9:7f:4f:02 rssi: 21, ctl: 05:21:00, ext: -128:-128:-128
[  964.420000] 6c:23:b9:7f:4f:02 rssi: 20, ctl: 07:20:01, ext: -128:-128:-128
[  964.440000] 6c:23:b9:7f:4f:02 rssi: 20, ctl: 03:20:04, ext: -128:-128:-128
[  964.620000] 6c:23:b9:7f:4f:02 rssi: 20, ctl: 11:19:06, ext: -128:-128:-128
[  964.640000] 6c:23:b9:7f:4f:02 rssi: 20, ctl: 12:20:06, ext: -128:-128:-128
[  964.660000] 6c:23:b9:7f:4f:02 rssi: 18, ctl: 12:17:07, ext: -128:-128:-128
[  965.180000] 6c:23:b9:7f:4f:02 rssi: 63, ctl: 59:61:51, ext: -128:-128:-128
[  965.200000] 6c:23:b9:7f:4f:02 rssi: 63, ctl: 59:60:53, ext: -128:-128:-128
[  965.220000] 6c:23:b9:7f:4f:02 rssi: 64, ctl: 60:62:52, ext: -128:-128:-128
[  965.330000] 6c:23:b9:7f:4f:02 rssi: 65, ctl: 61:63:53, ext: -128:-128:-128

As I undesrstand it, rssi values around 20 correspond to frames sent on channel 
on which my AP is configured (11 in that case) and values above 60 correspond to 
probe requests sent at channel 10 (reg. domain is set to 11 channels on device). 
Is that correct interpretation?

Is there any way to filter out frames received on other channels (so I only 
receive frames from channel on which my AP is configured)? Thresholding the 
signal level won't be a good solution: I won't be able to distinguish frames 
received on different channel from frames received from device which is far 
away. Filtering in time is also tricky as it involves finding out interval in 
which device is performing scans.

Maybe it's possible to somehow narrow down the width of rx band?

I will be grateful for any tips!

with regards,
Lukasz

[ath9k-devel] ath9k: signal level of rxed probe req.

[Guido Iribarren]

On Thu, Jun 21, 2012 at 5:39 PM, Lukasz <zmielony@poczta.onet.pl> wrote:
> Hi,
>

> I'm observing following behaviour (I don't have good radio background, so please
> correct me if I'm wrong):
> it seems that device (eg. sony xperia x10 with Android and TI wlan chip; other
> devices behave in similar way) is sending probe requests on different channels.
That's correct

> If my AP is configured on channel 11, it will also receive probe requests sent
> on channel 10, but with lower signal level.
That's also correct, you're observing "adjacent channel interference"
which means if a device that has a really strong signal (or is really
close) sends a packet on a channel adjacent to the one your radio is
tuned to, you'll hear it anyway, with a low signal.
Check the graphs on
https://en.wikipedia.org/wiki/IEEE_802.11#Channels_and_international_compatibility

>
> As I undesrstand it, rssi values around 20 correspond to frames sent on channel
> on which my AP is configured (11 in that case) and values above 60 correspond to
> probe requests sent at channel 10 (reg. domain is set to 11 channels on device).
> Is that correct interpretation?
Correct. I've seen more extreme cases (that same attenuation of 40 db
between channel as far apart as 1 and 11)

>
> Is there any way to filter out frames received on other channels (so I only
> receive frames from channel on which my AP is configured)? Thresholding the
> signal level won't be a good solution: I won't be able to distinguish frames
> received on different channel from frames received from device which is far
> away. Filtering in time is also tricky as it involves finding out interval in
> which device is performing scans.
>
> Maybe it's possible to somehow narrow down the width of rx band?

I can't speak at the radio/driver level since i'm not a programmer,
but maybe you can dissect the packet on a higher layer:
on wireshark I can see the probes include a tag (set by the sending
device) with the channel the probe was sent.
the fieldname in wireshark is "wlan_mgt.ds.current_channel"
and it's located on a tag with "wlan_mgt.tag.number"=3

It may not be the easiest way (you have to dissect the probe bytes)
but you'll have no doubt that's the channel the probe was originally
sent in.

just my 2c

Good luck! and please post any interesting results :)

Guido

[ath9k-devel] ath9k: signal level of rxed probe req.

[Holger Schurig]

> Is there any way to filter out frames received on other channels (so I only
> receive frames from channel on which my AP is configured)?

No, there isn't. Suppose the probe request was sent on channel 10. And
your AP is on channel 11. Then your AP actually really receives the
probe request on channel 11. Those channels are overlapping, after
all. Also, then "received channel" information in some wiretap header
(available on some monitoring interface) would also indicate channel
11.

You may use a heuristics: then you receive probe requests, record
their mac, signal level and a time stamp. If you get another probe
requets from the same MAC and the time is similar to what you already
have, then use the higher signal. That will work because a probing
client usually probes on different frequencies within a short timespan
(around 100 ms per channel).

[ath9k-devel] ath9k: signal level of rxed probe req.

[Guido Iribarren]

On Fri, Jun 22, 2012 at 3:42 AM, Holger Schurig
<holgerschurig@googlemail.com> wrote:

> all. Also, then "received channel" information in some wiretap header
> (available on some monitoring interface) would also indicate channel
> 11.
I agree the wiretap header would indicate the wrong channel, but AFAIU
if you look inside the probe bytes (instead of the header) you can
find (if the sending device was nice enough to set it) a tagged
parameter with the original channel the packet was sent to.

> You may use a heuristics: then you receive probe requests, record
> their mac, signal level and a time stamp. If you get another probe
> requets from the same MAC and the time is similar to what you already
> have, then use the higher signal. That will work because a probing
> client usually probes on different frequencies within a short timespan
> (around 100 ms per channel).
Nice idea!

[ath9k-devel] ath9k: signal level of rxed probe req.

[Holger Schurig]

Beacon packets from the access point contain a IE (information
element) with the channel.

But to the best of my knowledge probe packets from random clients
don't contain that.

[ath9k-devel] ath9k: signal level of rxed probe req.

[Guido Iribarren]

On Fri, Jun 22, 2012 at 5:04 AM, Holger Schurig
<holgerschurig@googlemail.com> wrote:
> But to the best of my knowledge probe packets from random clients
> don't contain that.

After a second check, you're 50% correct :P
The first probe request i stumbled with before writing the email,
turned out to be an exception, and i didn't bother to look for more (i
had the remembrance of having come across this tag before)

Probes requests coming from mac 00:25:d3:xx:xx:xx (random usb dongle)
or c4:17:fe:xx:xx:xx (honhai broadcom)  do in fact contain a "DS
Parameter set" with the channel, but seems that those particular
clients are overly cooperative.

other probe requests from mac 00:15:6d:xx:xx:xx (ubiquity) as well as
8c:71:f8:xx:xx:xx (Samsung smartphone), much shorter in length,
announce only the supported rates :(

So it seems you can't rely on that Lukasz, sorry for the mislead

What Holger suggested should do the job

Cheers!

[ath9k-devel] ath9k: signal level of rxed probe req.

[Lukasz]

On 06/22/2012 08:42 AM, Holger Schurig wrote:
>> Is there any way to filter out frames received on other channels (so I only
>> receive frames from channel on which my AP is configured)?
>
> No, there isn't. Suppose the probe request was sent on channel 10. And
> your AP is on channel 11. Then your AP actually really receives the
> probe request on channel 11. Those channels are overlapping, after
> all. Also, then "received channel" information in some wiretap header
> (available on some monitoring interface) would also indicate channel
> 11.
>
> You may use a heuristics: then you receive probe requests, record
> their mac, signal level and a time stamp. If you get another probe
> requets from the same MAC and the time is similar to what you already
> have, then use the higher signal. That will work because a probing
> client usually probes on different frequencies within a short timespan
> (around 100 ms per channel).
>

Actually I'm doing it this way now. The problem is that different devices use 
different scan interval, also time of channel switch doesn't seem to be constant 
(even for the same device). And it sometimes happens that not all frames are 
being received by AP. So it's quite tricky to find out good filter timing.

Anyway, I think I will have to improve my current filtering implementation :)

Thank you for answers!

with regards,
Lukasz