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

[Lukasz <zmielony@poczta.onet.pl>]

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