[ath9k-devel] Unrealistic RSSI values being reported

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

I recently upgraded to compat-wireless-3.1-rc8 from 
compat-wireless-2.6.39-1-sn and have discovered an interesting behavior. 
When in monitor mode I use the signal strength field reported in 
radiotap and with 3.1 I am now getting a range of values. The more 
interesting ones are all the frames reporting a signal of 110+ dBm. To 
see what is being pulled from the descriptors I dumped rs->rs_rssi to 
klog when the value was larger than 95. Below is a snippet showing the 
ranging values,

Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.907908] [ath9k]: RSSI 107
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.911697] [ath9k]: RSSI -61
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.913553] [ath9k]: RSSI -119
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.913562] [ath9k]: RSSI -59
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.913570] [ath9k]: RSSI -94
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.915880] [ath9k]: RSSI 119
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.915890] [ath9k]: RSSI -109
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.915898] [ath9k]: RSSI 123
Nov  3 15:00:03 dpsmith-dev-system kernel: [ 5319.917743] [ath9k]: RSSI 101

A couple of data points,
  1. I have tested two different cards, one having AR9106+AR9160 and one 
with an AR9382.

  2. It appears that it is always the same devices that this occurs for, 
e.g. pretty confident there are some devices that I collected that I did 
not see anything out of the 3-10dBm range

I know 2.6.39 -> 3.1 is a bit of a jump, but I wanted to push this to 
the community to see if there are some thoughts or opinions while I dig 
deeper. My next step is to see if it occurs in 3.0 which should help 
give me a narrow set of patches to review/bisect to see at what point 
this was introduced. I would suspect it to be an initval issue, but the 
two chips I have should have different initval sets. Any thoughts or 
suggestions would be greatly appreciated.

dps

[ath9k-devel] Unrealistic RSSI values being reported

[Mohammed Shafi]

Hi Daniel,

On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith <viscous.liquid@gmail.com> wrote:
> I recently upgraded to compat-wireless-3.1-rc8 from
> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior.
> When in monitor mode I use the signal strength field reported in
> radiotap and with 3.1 I am now getting a range of values. The more
> interesting ones are all the frames reporting a signal of 110+ dBm. To
> see what is being pulled from the descriptors I dumped rs->rs_rssi to
> klog when the value was larger than 95. Below is a snippet showing the
> ranging values,

i tried with the AR9382 card in 3.1.0-wl with the attached debug
patch, can you please give a sample log with the patch applied and
putting the interface in monitor mode. did you print/check rs_rssi
somewhere else?
did you also try with the latest package
http://linuxwireless.org/download/compat-wireless-2.6/

>
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.907908] [ath9k]: RSSI 107
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.911697] [ath9k]: RSSI -61
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.913553] [ath9k]: RSSI -119
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.913562] [ath9k]: RSSI -59
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.913570] [ath9k]: RSSI -94
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.915880] [ath9k]: RSSI 119
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.915890] [ath9k]: RSSI -109
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.915898] [ath9k]: RSSI 123
> Nov ?3 15:00:03 dpsmith-dev-system kernel: [ 5319.917743] [ath9k]: RSSI 101
>
> A couple of data points,
> ?1. I have tested two different cards, one having AR9106+AR9160 and one
> with an AR9382.
>
> ?2. It appears that it is always the same devices that this occurs for,
> e.g. pretty confident there are some devices that I collected that I did
> not see anything out of the 3-10dBm range
>
> I know 2.6.39 -> 3.1 is a bit of a jump, but I wanted to push this to
> the community to see if there are some thoughts or opinions while I dig
> deeper. My next step is to see if it occurs in 3.0 which should help
> give me a narrow set of patches to review/bisect to see at what point
> this was introduced. I would suspect it to be an initval issue, but the
> two chips I have should have different initval sets. Any thoughts or
> suggestions would be greatly appreciated.
>
> dps
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: print-rssi.patch
Type: text/x-diff
Size: 631 bytes
Desc: not available
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20111104/2a7fa2e3/attachment.patch 

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

On 11/3/2011 7:10 PM, Mohammed Shafi wrote:
> Hi Daniel,
>
> On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith<viscous.liquid@gmail.com>  wrote:
>> I recently upgraded to compat-wireless-3.1-rc8 from
>> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior.
>> When in monitor mode I use the signal strength field reported in
>> radiotap and with 3.1 I am now getting a range of values. The more
>> interesting ones are all the frames reporting a signal of 110+ dBm. To
>> see what is being pulled from the descriptors I dumped rs->rs_rssi to
>> klog when the value was larger than 95. Below is a snippet showing the
>> ranging values,
> i tried with the AR9382 card in 3.1.0-wl with the attached debug
> patch, can you please give a sample log with the patch applied and
> putting the interface in monitor mode. did you print/check rs_rssi
> somewhere else?
> did you also try with the latest package
> http://linuxwireless.org/download/compat-wireless-2.6/

First I apologize as I forgot to mention I am putting the channel into 
HT40 mode and the frames coming in are non-HT as that is the stated that 
the issue was reported to me. I have not ran test yet to see if it 
occurs with the channel in HT20 and non-ht mode. Also I have one more 
test to run on compat-wireless-3.0-2 but it looks like I am not seeing 
any issue with it.

For reference here is the patch from my change, very similar to yours 
except that I didn't dump signal or noise.

@@ -1015,6 +1015,8 @@ static int ath9k_rx_skb_preprocess(struct 
ath_common *common,
         rx_status->snr = rx_stats->rs_rssi;
         rx_status->antenna = rx_stats->rs_antenna;
         rx_status->flag |= RX_FLAG_MACTIME_MPDU;
+       if (rx_stats->rs_rssi > 95 || rx_stats->rs_rssi < 0)
+               printk("[ath9k]: RSSI %hhd\n", rx_stats->rs_rssi);

         return 0;
  }

I will rerun it with your additions so you can see those values as well. 
Yes I can also test it with a nightly package to see if it has been 
resolved.

Thanks for the Help!

dps

[ath9k-devel] Unrealistic RSSI values being reported

[Mohammed Shafi]

On Fri, Nov 4, 2011 at 4:57 PM, Daniel Smith <viscous.liquid@gmail.com> wrote:
> On 11/3/2011 7:10 PM, Mohammed Shafi wrote:
>> Hi Daniel,
>>
>> On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith<viscous.liquid@gmail.com> ?wrote:
>>> I recently upgraded to compat-wireless-3.1-rc8 from
>>> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior.
>>> When in monitor mode I use the signal strength field reported in
>>> radiotap and with 3.1 I am now getting a range of values. The more
>>> interesting ones are all the frames reporting a signal of 110+ dBm. To
>>> see what is being pulled from the descriptors I dumped rs->rs_rssi to
>>> klog when the value was larger than 95. Below is a snippet showing the
>>> ranging values,
>> i tried with the AR9382 card in 3.1.0-wl with the attached debug
>> patch, can you please give a sample log with the patch applied and
>> putting the interface in monitor mode. did you print/check rs_rssi
>> somewhere else?
>> did you also try with the latest package
>> http://linuxwireless.org/download/compat-wireless-2.6/
>
> First I apologize as I forgot to mention I am putting the channel into
> HT40 mode and the frames coming in are non-HT as that is the stated that
> the issue was reported to me. I have not ran test yet to see if it
> occurs with the channel in HT20 and non-ht mode. Also I have one more
> test to run on compat-wireless-3.0-2 but it looks like I am not seeing
> any issue with it.
>
> For reference here is the patch from my change, very similar to yours
> except that I didn't dump signal or noise.
>
> @@ -1015,6 +1015,8 @@ static int ath9k_rx_skb_preprocess(struct
> ath_common *common,
> ? ? ? ? rx_status->snr = rx_stats->rs_rssi;
> ? ? ? ? rx_status->antenna = rx_stats->rs_antenna;
> ? ? ? ? rx_status->flag |= RX_FLAG_MACTIME_MPDU;
> + ? ? ? if (rx_stats->rs_rssi > 95 || rx_stats->rs_rssi < 0)
> + ? ? ? ? ? ? ? printk("[ath9k]: RSSI %hhd\n", rx_stats->rs_rssi);

hi Daniel,

some values i got
signal = noise + rs_rssi

noise = -95 , rs_rssi = 55, signal = -40
rs_rssi has values like 65, 57, 52, 29, 53, 55, 21 , 35 , 50.
sure values > 95 does not seems to occur for me.  sure i can try with
HT40 mode and put these prints
will be out of station for 3 days, will try to debug once , hope some
other developers might provide more inputs


>
> ? ? ? ? return 0;
> ?}
>
> I will rerun it with your additions so you can see those values as well.
> Yes I can also test it with a nightly package to see if it has been
> resolved.
>
> Thanks for the Help!
>
> dps
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

On 11/3/2011 7:10 PM, Mohammed Shafi wrote:
> Hi Daniel,
>
> i tried with the AR9382 card in 3.1.0-wl with the attached debug
> patch, can you please give a sample log with the patch applied and
> putting the interface in monitor mode. did you print/check rs_rssi
> somewhere else?
> did you also try with the latest package
> http://linuxwireless.org/download/compat-wireless-2.6/
>

Alright, so I built compat-wireless-2011-11-03 (the latest when I looked 
this morning), although in klog it reported as 
compat-wireless-2011-10-14. Below are snippets from the logs. Some 
things I noticed is that for beacons and probes I am get acceptable 
values, but traffic(data) frames are the ones that have the unrealistic 
values,. Although if the AR9832 really had a RX sensitivity of -198dB, 
as it claims on one of the frames, we could set some serious distance 
records (^_^).

Configuration commands,
iw wlan9 set type monitor
iw wlan9 set channel 4 HT40+

Version info:
Nov  4 12:37:23 dpsmith-dev-system kernel: [83160.841129] 
Compat-wireless backport release: compat-wireless-2011-10-14
Nov  4 12:37:23 dpsmith-dev-system kernel: [83160.841138] Backport based 
on linux-next.git next-20111025


The AR9382 card:
Nov  4 12:37:24 dpsmith-dev-system kernel: [83160.930301] ieee80211 
phy0: Atheros AR9300 Rev:3 mem=0xfd7c0000, irq=16
Nov  4 12:37:24 dpsmith-dev-system kernel: [83160.930337] ath9k 
0000:0c:08.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18


The AR9160 card:
Nov  4 12:37:25 dpsmith-dev-system kernel: [83162.531047] ieee80211 
phy1: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0 mem=0xfd800000, irq=18
Nov  4 12:37:25 dpsmith-dev-system kernel: [83162.531072] ath9k 
0000:0c:09.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19


AR9160 beacons and probes,
Nov  4 12:38:09 dpsmith-dev-system kernel: [83205.921245] noise = -88, 
rs_rssi = 43, signal =-45
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.023657] noise = -88, 
rs_rssi = 40, signal =-48
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.126067] noise = -88, 
rs_rssi = 40, signal =-48
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.161743] noise = -88, 
rs_rssi = 39, signal =-49
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.224044] noise = -88, 
rs_rssi = 41, signal =-47
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.224052] noise = -88, 
rs_rssi = 6, signal =-82
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.228482] noise = -88, 
rs_rssi = 39, signal =-49
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.330891] noise = -88, 
rs_rssi = 41, signal =-47
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.433304] noise = -88, 
rs_rssi = 41, signal =-47
Nov  4 12:38:09 dpsmith-dev-system kernel: [83206.535713] noise = -88, 
rs_rssi = 42, signal =-46


AR9160 large values (obtained with: cat kern.log-wlan9-11-03 |grep 
'noise' | grep -v '=-'),
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.704886] noise = -88, 
rs_rssi = 99, signal =11
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.707048] noise = -88, 
rs_rssi = 114, signal =26
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.707061] noise = -88, 
rs_rssi = 107, signal =19
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.713837] noise = -88, 
rs_rssi = 121, signal =33
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.800813] noise = -88, 
rs_rssi = 114, signal =26
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.800849] noise = -88, 
rs_rssi = 114, signal =26
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.803943] noise = -88, 
rs_rssi = 114, signal =26
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.812570] noise = -88, 
rs_rssi = 91, signal =3
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.833527] noise = -88, 
rs_rssi = 91, signal =3
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.852020] noise = -88, 
rs_rssi = 122, signal =34
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.867188] noise = -88, 
rs_rssi = 97, signal =9
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.883733] noise = -88, 
rs_rssi = 124, signal =36
Nov  4 12:48:44 dpsmith-dev-system kernel: [83841.887835] noise = -88, 
rs_rssi = 124, signal =36

Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.222768] noise = -88, 
rs_rssi = -70, signal =-158
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.225734] noise = -88, 
rs_rssi = -57, signal =-145
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.225744] noise = -88, 
rs_rssi = -100, signal =-188
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.228756] noise = -88, 
rs_rssi = -41, signal =-129
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.228766] noise = -88, 
rs_rssi = -50, signal =-138
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.238307] noise = -88, 
rs_rssi = -59, signal =-147
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.238317] noise = -88, 
rs_rssi = -41, signal =-129
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.239728] noise = -88, 
rs_rssi = -80, signal =-168
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.349986] noise = -88, 
rs_rssi = -92, signal =-180
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.349999] noise = -88, 
rs_rssi = -92, signal =-180
Nov  4 12:48:45 dpsmith-dev-system kernel: [83842.350009] noise = -88, 
rs_rssi = -18, signal =-106


AR9382 beacons and probes,
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.575367] noise = -95, 
rs_rssi = 28, signal =-67
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.577432] noise = -95, 
rs_rssi = 44, signal =-51
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.577445] noise = -95, 
rs_rssi = 48, signal =-47
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.578581] noise = -95, 
rs_rssi = 44, signal =-51
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.580742] noise = -95, 
rs_rssi = 45, signal =-50
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.580753] noise = -95, 
rs_rssi = 45, signal =-50
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.581369] noise = -95, 
rs_rssi = 47, signal =-48
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.582133] noise = -95, 
rs_rssi = 48, signal =-47
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.582771] noise = -95, 
rs_rssi = 48, signal =-47
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.582780] noise = -95, 
rs_rssi = 28, signal =-67
Nov  4 13:02:48 dpsmith-dev-system kernel: [84685.582788] noise = -95, 
rs_rssi = 49, signal =-46


AR9382 large values,
Nov  4 13:02:49 dpsmith-dev-system kernel: [84686.866417] noise = -95, 
rs_rssi = 117, signal =22
Nov  4 13:02:49 dpsmith-dev-system kernel: [84686.867481] noise = -95, 
rs_rssi = 100, signal =5
Nov  4 13:02:50 dpsmith-dev-system kernel: [84687.056185] noise = -95, 
rs_rssi = 108, signal =13
Nov  4 13:02:51 dpsmith-dev-system kernel: [84688.101812] noise = -95, 
rs_rssi = 121, signal =26
Nov  4 13:02:51 dpsmith-dev-system kernel: [84688.184731] noise = -95, 
rs_rssi = 118, signal =23
Nov  4 13:02:53 dpsmith-dev-system kernel: [84690.676674] noise = -95, 
rs_rssi = 116, signal =21
Nov  4 13:02:58 dpsmith-dev-system kernel: [84695.616568] noise = -95, 
rs_rssi = 120, signal =25
Nov  4 13:02:58 dpsmith-dev-system kernel: [84695.616578] noise = -95, 
rs_rssi = 102, signal =7
Nov  4 13:02:58 dpsmith-dev-system kernel: [84695.737242] noise = -95, 
rs_rssi = 106, signal =11
Nov  4 13:02:58 dpsmith-dev-system kernel: [84695.741015] noise = -95, 
rs_rssi = 109, signal =14

Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.016861] noise = -95, 
rs_rssi = -103, signal =-198
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.017702] noise = -95, 
rs_rssi = -6, signal =-101
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.437538] noise = -95, 
rs_rssi = -91, signal =-186
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.443453] noise = -95, 
rs_rssi = -47, signal =-142
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.444890] noise = -95, 
rs_rssi = -59, signal =-154
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.446049] noise = -95, 
rs_rssi = -94, signal =-189
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.447909] noise = -95, 
rs_rssi = -22, signal =-117
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.452528] noise = -95, 
rs_rssi = -55, signal =-150
Nov  4 13:06:39 dpsmith-dev-system kernel: [84916.813274] noise = -95, 
rs_rssi = -43, signal =-138

v/r,
dps

[ath9k-devel] Unrealistic RSSI values being reported

[Mohammed Shafi]

On Fri, Nov 4, 2011 at 11:20 PM, Daniel Smith <viscous.liquid@gmail.com> wrote:
> On 11/3/2011 7:10 PM, Mohammed Shafi wrote:
>> Hi Daniel,
>>
>> i tried with the AR9382 card in 3.1.0-wl with the attached debug
>> patch, can you please give a sample log with the patch applied and
>> putting the interface in monitor mode. did you print/check rs_rssi
>> somewhere else?
>> did you also try with the latest package
>> http://linuxwireless.org/download/compat-wireless-2.6/
>>
>
> Alright, so I built compat-wireless-2011-11-03 (the latest when I looked
> this morning), although in klog it reported as
> compat-wireless-2011-10-14. Below are snippets from the logs. Some
> things I noticed is that for beacons and probes I am get acceptable
> values, but traffic(data) frames are the ones that have the unrealistic
> values,. Although if the AR9832 really had a RX sensitivity of -198dB,
> as it claims on one of the frames, we could set some serious distance
> records (^_^).
>
> Configuration commands,
> iw wlan9 set type monitor
> iw wlan9 set channel 4 HT40+
>
> Version info:
> Nov ?4 12:37:23 dpsmith-dev-system kernel: [83160.841129]
> Compat-wireless backport release: compat-wireless-2011-10-14
> Nov ?4 12:37:23 dpsmith-dev-system kernel: [83160.841138] Backport based
> on linux-next.git next-20111025
>
>
> The AR9382 card:
> Nov ?4 12:37:24 dpsmith-dev-system kernel: [83160.930301] ieee80211
> phy0: Atheros AR9300 Rev:3 mem=0xfd7c0000, irq=16
> Nov ?4 12:37:24 dpsmith-dev-system kernel: [83160.930337] ath9k
> 0000:0c:08.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
>
>
> The AR9160 card:
> Nov ?4 12:37:25 dpsmith-dev-system kernel: [83162.531047] ieee80211
> phy1: Atheros AR9160 MAC/BB Rev:1 AR5133 RF Rev:b0 mem=0xfd800000, irq=18
> Nov ?4 12:37:25 dpsmith-dev-system kernel: [83162.531072] ath9k
> 0000:0c:09.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
>
>
> AR9160 beacons and probes,
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83205.921245] noise = -88,
> rs_rssi = 43, signal =-45
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.023657] noise = -88,
> rs_rssi = 40, signal =-48
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.126067] noise = -88,
> rs_rssi = 40, signal =-48
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.161743] noise = -88,
> rs_rssi = 39, signal =-49
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.224044] noise = -88,
> rs_rssi = 41, signal =-47
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.224052] noise = -88,
> rs_rssi = 6, signal =-82
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.228482] noise = -88,
> rs_rssi = 39, signal =-49
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.330891] noise = -88,
> rs_rssi = 41, signal =-47
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.433304] noise = -88,
> rs_rssi = 41, signal =-47
> Nov ?4 12:38:09 dpsmith-dev-system kernel: [83206.535713] noise = -88,
> rs_rssi = 42, signal =-46
>
>
> AR9160 large values (obtained with: cat kern.log-wlan9-11-03 |grep
> 'noise' | grep -v '=-'),
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.704886] noise = -88,
> rs_rssi = 99, signal =11
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.707048] noise = -88,
> rs_rssi = 114, signal =26
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.707061] noise = -88,
> rs_rssi = 107, signal =19
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.713837] noise = -88,
> rs_rssi = 121, signal =33
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.800813] noise = -88,
> rs_rssi = 114, signal =26
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.800849] noise = -88,
> rs_rssi = 114, signal =26
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.803943] noise = -88,
> rs_rssi = 114, signal =26
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.812570] noise = -88,
> rs_rssi = 91, signal =3
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.833527] noise = -88,
> rs_rssi = 91, signal =3
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.852020] noise = -88,
> rs_rssi = 122, signal =34
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.867188] noise = -88,
> rs_rssi = 97, signal =9
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.883733] noise = -88,
> rs_rssi = 124, signal =36
> Nov ?4 12:48:44 dpsmith-dev-system kernel: [83841.887835] noise = -88,
> rs_rssi = 124, signal =36
>
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.222768] noise = -88,
> rs_rssi = -70, signal =-158
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.225734] noise = -88,
> rs_rssi = -57, signal =-145
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.225744] noise = -88,
> rs_rssi = -100, signal =-188
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.228756] noise = -88,
> rs_rssi = -41, signal =-129
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.228766] noise = -88,
> rs_rssi = -50, signal =-138
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.238307] noise = -88,
> rs_rssi = -59, signal =-147
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.238317] noise = -88,
> rs_rssi = -41, signal =-129
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.239728] noise = -88,
> rs_rssi = -80, signal =-168
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.349986] noise = -88,
> rs_rssi = -92, signal =-180
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.349999] noise = -88,
> rs_rssi = -92, signal =-180
> Nov ?4 12:48:45 dpsmith-dev-system kernel: [83842.350009] noise = -88,
> rs_rssi = -18, signal =-106
>
>
> AR9382 beacons and probes,
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.575367] noise = -95,
> rs_rssi = 28, signal =-67
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.577432] noise = -95,
> rs_rssi = 44, signal =-51
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.577445] noise = -95,
> rs_rssi = 48, signal =-47
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.578581] noise = -95,
> rs_rssi = 44, signal =-51
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.580742] noise = -95,
> rs_rssi = 45, signal =-50
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.580753] noise = -95,
> rs_rssi = 45, signal =-50
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.581369] noise = -95,
> rs_rssi = 47, signal =-48
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582133] noise = -95,
> rs_rssi = 48, signal =-47
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582771] noise = -95,
> rs_rssi = 48, signal =-47
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582780] noise = -95,
> rs_rssi = 28, signal =-67
> Nov ?4 13:02:48 dpsmith-dev-system kernel: [84685.582788] noise = -95,
> rs_rssi = 49, signal =-46
>
>
> AR9382 large values,
> Nov ?4 13:02:49 dpsmith-dev-system kernel: [84686.866417] noise = -95,
> rs_rssi = 117, signal =22
> Nov ?4 13:02:49 dpsmith-dev-system kernel: [84686.867481] noise = -95,
> rs_rssi = 100, signal =5
> Nov ?4 13:02:50 dpsmith-dev-system kernel: [84687.056185] noise = -95,
> rs_rssi = 108, signal =13
> Nov ?4 13:02:51 dpsmith-dev-system kernel: [84688.101812] noise = -95,
> rs_rssi = 121, signal =26
> Nov ?4 13:02:51 dpsmith-dev-system kernel: [84688.184731] noise = -95,
> rs_rssi = 118, signal =23
> Nov ?4 13:02:53 dpsmith-dev-system kernel: [84690.676674] noise = -95,
> rs_rssi = 116, signal =21
> Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.616568] noise = -95,
> rs_rssi = 120, signal =25
> Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.616578] noise = -95,
> rs_rssi = 102, signal =7
> Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.737242] noise = -95,
> rs_rssi = 106, signal =11
> Nov ?4 13:02:58 dpsmith-dev-system kernel: [84695.741015] noise = -95,
> rs_rssi = 109, signal =14
>
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.016861] noise = -95,
> rs_rssi = -103, signal =-198
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.017702] noise = -95,
> rs_rssi = -6, signal =-101
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.437538] noise = -95,
> rs_rssi = -91, signal =-186
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.443453] noise = -95,
> rs_rssi = -47, signal =-142
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.444890] noise = -95,
> rs_rssi = -59, signal =-154
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.446049] noise = -95,
> rs_rssi = -94, signal =-189
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.447909] noise = -95,
> rs_rssi = -22, signal =-117
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.452528] noise = -95,
> rs_rssi = -55, signal =-150
> Nov ?4 13:06:39 dpsmith-dev-system kernel: [84916.813274] noise = -95,
> rs_rssi = -43, signal =-138
>


Daniel,

thanks for the detail info. i will just do this. run a ping traffic
betweem some AP and another card say AR9280 and sniff those data
packets in my AR9382 to recreate what you are saying.

> v/r,
> dps
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

Just wanted to follow-up to let everyone know the status and for
anyone people that may stumble on this from a search. Also, I have a
pcap file from one of the captures done with 2.6.39-1-sn if anyone
wants to inspect the frames themselves, just email me directly if
would like it.

Some observations made in limited testing across various version of
compat-wireless.
 * found that 2.6.39-1-sn exhibited the same behavior
 * it always seemed that it was HT traffic that this would occur with
 * tested an 802.11g client right next to the collection antenna, no frames
     from that client would trigger an invalid value
 * it was always the same two devices, an HTC phone and a Motorola phone
 * found that the per chain RSSIs were always valid even when the combined
     RSSI was not
 * when the combined RSSI was valid and not equal to the max per chain
     RSSI, it was typically was 7 dB or less

So with 2.6.39 demonstrating the behavior as well I did not want to expend
the effort to find a version that this bug did not occur in to do a bisect. To
that end I incorporated a fix-up/work-around/hack to attempt to detect
when a bad combined RSSI, and if so then substitute in the max per
chain RSSI.


@@ -566,9 +566,20 @@ EXPORT_SYMBOL(ath9k_hw_resettxqueue);
 int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
                        struct ath_rx_status *rs, u64 tsf)
 {
+/* shamelessly stole from linux.h */
+#define max3(x, y, z) ({                        \
+       typeof(x) _max1 = (x);                  \
+       typeof(y) _max2 = (y);                  \
+       typeof(z) _max3 = (z);                  \
+       (void) (&_max1 == &_max2);              \
+       (void) (&_max1 == &_max3);              \
+       _max1 > _max2 ? (_max1 > _max3 ? _max1 : _max3) : \
+       (_max2 > _max3 ? _max2 : _max3); })
+
        struct ar5416_desc ads;
        struct ar5416_desc *adsp = AR5416DESC(ds);
        u32 phyerr;
+       int8_t max_rssi;

        if ((adsp->ds_rxstatus8 & AR_RxDone) == 0)
                return -EINPROGRESS;
@@ -604,6 +615,9 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
                rs->rs_rssi_ext2 = MS(ads.ds_rxstatus4,
                                                AR_RxRSSIAnt12);
        }
+       max_rssi = max3(rs->rs_rssi_ctl0,rs->rs_rssi_ctl1,rs->rs_rssi_ctl2);
+       if (unlikely( abs(rs->rs_rssi - max_rssi) > 10))
+               rs->rs_rssi = max_rssi;
        if (ads.ds_rxstatus8 & AR_RxKeyIdxValid)
                rs->rs_keyix = MS(ads.ds_rxstatus8, AR_KeyIdx);
        else
@@ -650,6 +664,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct
ath_desc *ds,
        }

        return 0;
+#undef max3
 }
 EXPORT_SYMBOL(ath9k_hw_rxprocdesc);

[ath9k-devel] Unrealistic RSSI values being reported

[Adrian Chadd]

Hi,

See if those valid or invalid RSSI's coincide with aggregate frames.

ath9k_process_rssi() has a bit of logic which only considers frames
that aren't part of continuing aggregate:

        if (rx_stats->rs_rssi != ATH9K_RSSI_BAD && !rx_stats->rs_moreaggr)
                ATH_RSSI_LPF(sc->last_rssi, rx_stats->rs_rssi);

.. ie, rs_moreaggr is set if the frame is part of an aggregate, clear
if it's not an aggregate or is the last frame in an aggregate.


Adrian

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

On 11/21/2011 3:09 PM, Adrian Chadd wrote:
> Hi,
>
> See if those valid or invalid RSSI's coincide with aggregate frames.
>
> ath9k_process_rssi() has a bit of logic which only considers frames
> that aren't part of continuing aggregate:
>
>          if (rx_stats->rs_rssi != ATH9K_RSSI_BAD&&  !rx_stats->rs_moreaggr)
>                  ATH_RSSI_LPF(sc->last_rssi, rx_stats->rs_rssi);
>
> .. ie, rs_moreaggr is set if the frame is part of an aggregate, clear
> if it's not an aggregate or is the last frame in an aggregate.
>
>
> Adrian


Hey Adrian!


Excellent call! So in mac.c:ath9k_hw_rxprocdesc() I put a three printk 
(in the following order) for when I detect the out-of-bounds rssi, an 
aggregate, and if there is more to the aggregate. As you can see below 
when my check is triggered on aggregate frames only.

Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.298868] [ath9k] frame 
is aggr: false
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300420] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300422] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300426] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300433] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300435] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300439] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300444] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300446] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300450] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300456] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.300460] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302637] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302641] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302645] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302654] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302657] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302662] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302670] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302674] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302679] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302687] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302692] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302700] [ath9k] frame 
is aggr: false
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302707] [ath9k] frame 
is aggr: false
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302714] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302717] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.302722] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304683] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304686] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304689] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304696] [ath9k] 
overriding RSSI
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304698] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304701] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304707] [ath9k] frame 
is aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304710] [ath9k] frame 
has more aggr: true
Nov 22 12:20:03 dpsmith-dev-system kernel: [357695.304716] [ath9k] frame 
is aggr: false

To verify that it was only tripped on aggregate frames,

$ grep -A 1 overriding /var/log/kern.log|grep -B 1 false
Nov 22 08:09:09 dpsmith-dev-system kernel: [342641.360141] [ath9k] 
overriding RSSI
Nov 22 08:09:09 dpsmith-dev-system kernel: [342641.360145] [ath9k] frame 
is aggr: false
--
Nov 22 08:14:53 dpsmith-dev-system kernel: [342985.292829] [ath9k] 
overriding RSSI
Nov 22 08:14:53 dpsmith-dev-system kernel: [342985.292834] [ath9k] frame 
is aggr: false
--
Nov 22 08:21:23 dpsmith-dev-system kernel: [343375.366725] [ath9k] 
overriding RSSI
Nov 22 08:21:23 dpsmith-dev-system kernel: [343375.366729] [ath9k] frame 
is aggr: false
--
Nov 22 12:25:06 dpsmith-dev-system kernel: [357998.381999] [ath9k] 
overriding RSSI
Nov 22 12:25:06 dpsmith-dev-system kernel: [357998.382004] [ath9k] frame 
is aggr: false

I did not print the combined and max RSSI, but I think these four are 
anomalies where abs(combined - max) was slightly over 10. Which probably 
was valid as 10 was chosen as a guesstimate more than a scientifically 
proven value.

So the question I have is that, is there a reason not to run 
ath9k_process_rssi on frames from a monitor interface? From what I read 
of that function as long as last_rssi != ATH_RSSI_DUMMY_MARKER then 
rs->rs_rssi will get set to last_rssi, which gets recalculated just 
before one of these incidents.

Thanks for the help!

Daniel

[ath9k-devel] Unrealistic RSSI values being reported

[Adrian Chadd]

On 23 November 2011 01:42, Daniel Smith <viscous.liquid@gmail.com> wrote:

> Excellent call! So in mac.c:ath9k_hw_rxprocdesc() I put a three printk
> (in the following order) for when I detect the out-of-bounds rssi, an
> aggregate, and if there is more to the aggregate. As you can see below
> when my check is triggered on aggregate frames only.

Ok. Does it trigger on aggregation frames w/ more, or not w/ more, or both?



adrian

[ath9k-devel] Unrealistic RSSI values being reported

[Mohammed Shafi]

On Fri, Nov 4, 2011 at 4:57 PM, Daniel Smith <viscous.liquid@gmail.com> wrote:
> On 11/3/2011 7:10 PM, Mohammed Shafi wrote:
>> Hi Daniel,
>>
>> On Fri, Nov 4, 2011 at 12:58 AM, Daniel Smith<viscous.liquid@gmail.com> ?wrote:
>>> I recently upgraded to compat-wireless-3.1-rc8 from
>>> compat-wireless-2.6.39-1-sn and have discovered an interesting behavior.
>>> When in monitor mode I use the signal strength field reported in
>>> radiotap and with 3.1 I am now getting a range of values. The more
>>> interesting ones are all the frames reporting a signal of 110+ dBm. To
>>> see what is being pulled from the descriptors I dumped rs->rs_rssi to
>>> klog when the value was larger than 95. Below is a snippet showing the
>>> ranging values,
>> i tried with the AR9382 card in 3.1.0-wl with the attached debug
>> patch, can you please give a sample log with the patch applied and
>> putting the interface in monitor mode. did you print/check rs_rssi
>> somewhere else?
>> did you also try with the latest package
>> http://linuxwireless.org/download/compat-wireless-2.6/
>
> First I apologize as I forgot to mention I am putting the channel into
> HT40 mode and the frames coming in are non-HT as that is the stated that
> the issue was reported to me. I have not ran test yet to see if it
> occurs with the channel in HT20 and non-ht mode. Also I have one more
> test to run on compat-wireless-3.0-2 but it looks like I am not seeing
> any issue with it.
>
> For reference here is the patch from my change, very similar to yours
> except that I didn't dump signal or noise.
>
> @@ -1015,6 +1015,8 @@ static int ath9k_rx_skb_preprocess(struct
> ath_common *common,
> ? ? ? ? rx_status->snr = rx_stats->rs_rssi;
> ? ? ? ? rx_status->antenna = rx_stats->rs_antenna;
> ? ? ? ? rx_status->flag |= RX_FLAG_MACTIME_MPDU;
> + ? ? ? if (rx_stats->rs_rssi > 95 || rx_stats->rs_rssi < 0)
> + ? ? ? ? ? ? ? printk("[ath9k]: RSSI %hhd\n", rx_stats->rs_rssi);
>
> ? ? ? ? return 0;
> ?}
>
> I will rerun it with your additions so you can see those values as well.
> Yes I can also test it with a nightly package to see if it has been
> resolved.

Hi Daniel,

sorry was busy with some other urgent work. a value upto 127 seems to
be valid for Atheros chipsets, bad -128
http://en.wikipedia.org/wiki/Received_signal_strength_indication  :)
further the negative value should be caught by the check in
ath9k_process_rssi unless my_beacon is 'false' hope i had not missed something.

        if (rx_stats->rs_rssi < 0)
                rx_stats->rs_rssi = 0;

i will test this behavior and do further investigation.


>
> Thanks for the Help!
>
> dps
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>



-- 
shafi

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

On 11/22/2011 6:05 PM, Adrian Chadd wrote:
>
> Ok. Does it trigger on aggregation frames w/ more, or not w/ more, or both?
>
>
>
> adrian

So here is the observed patterns,
   * When the RSSI override is triggered, rs_isaggr and rs_moreaggr is 
set(true)
   * When rs_isaggr and rs_moreaggr is set, overwhelmingly of those had the
         RSSI overridden but there were a few that were not
   * When rs_isaggr is set and rs_moreaggr is not set, the RSSI was 
never overridden.

Based on this and thinking about how ath9k_process_rssi works I don't 
see any other way but to leave my fix-up. The alternative would be in 
user-space I will have to remember that the signal strength for an 
aggregate series will come from the last frame in the aggregate. Is 
there another way that I am not thinking of?

Daniel

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

On 11/23/2011 1:06 AM, Mohammed Shafi wrote:
>
> Hi Daniel,
>
> sorry was busy with some other urgent work. a value upto 127 seems to
> be valid for Atheros chipsets, bad -128
> http://en.wikipedia.org/wiki/Received_signal_strength_indication  :)
> further the negative value should be caught by the check in
> ath9k_process_rssi unless my_beacon is 'false' hope i had not missed something.
>
>          if (rx_stats->rs_rssi<  0)
>                  rx_stats->rs_rssi = 0;
>
> i will test this behavior and do further investigation.
>
>

Hey Shafi,

No worries, I completely understand.

So while 127 is a valid value for the chip, the reality is that it would 
not be (legally) possible. if the noise floor is -90dBm and the RSSI was 
127 then the signal power at the antenna would have been 37dBm. Even if 
the TX antenna was right next to the RX antenna that would still be more 
powerful than what is legally allowed by the FCC. In this case the 
devices creating the offending traffic are Android smartphones (a HTC 
and a Motorola; based off of MAC), which typically have a max tx power 
around 15dBm, which again with a -90dBm noise floor would have a RSSI of 
105 in a zero-loss free space. All those numbers are theoretical so for 
a baseline I set a Nokia N900 right next to the antenna (antenna is ~5' 
away and has a 6' coax whip) the largest signal strength (rssi + noise) 
I saw was -29dBm.

For testing, take a look at the analysis that Adrian and I have been 
pursuing. It seems that the invalid RSSI occur for aggregate frames when 
there are still additional frames left in the aggregate, i.e. rs_isaggr 
and rs_moreaggr are both set.

Thanks for taking some time to help look at this!

Daniel

[ath9k-devel] Unrealistic RSSI values being reported

[Adrian Chadd]

Ok, cool. So I was right. :)

Yes, the nice solution would be to expose those aggregate frame
boundary delimiters to userland and then only marking those frames
with valid RSSI .. well, somehow.

The nicer solution would be to buffer those frames in an aggregate and
then assign them all a common RSSI. But ew.



Adrian

[ath9k-devel] Unrealistic RSSI values being reported

[Felix Fietkau]

On 2011-11-23 9:14 PM, Adrian Chadd wrote:
> Ok, cool. So I was right. :)
> 
> Yes, the nice solution would be to expose those aggregate frame
> boundary delimiters to userland and then only marking those frames
> with valid RSSI .. well, somehow.
> 
> The nicer solution would be to buffer those frames in an aggregate and
> then assign them all a common RSSI. But ew.
No need to buffer them in the driver, just do a lookahead on the DMA
ring. If necessary, defer processing until the last part of the
aggregate has been completed.

- Felix

[ath9k-devel] Unrealistic RSSI values being reported

[Daniel Smith]

On Wed, Nov 23, 2011 at 9:24 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-11-23 9:14 PM, Adrian Chadd wrote:
>> Ok, cool. So I was right. :)
>>
>> Yes, the nice solution would be to expose those aggregate frame
>> boundary delimiters to userland and then only marking those frames
>> with valid RSSI .. well, somehow.
>>
>> The nicer solution would be to buffer those frames in an aggregate and
>> then assign them all a common RSSI. But ew.
> No need to buffer them in the driver, just do a lookahead on the DMA
> ring. If necessary, defer processing until the last part of the
> aggregate has been completed.
>
> - Felix


Adrian,
Yes you were right, excellent call on your part. m(_ _)m

Felix,
I think the former would be more straight forward. The question I have
is what is the cost/benefit of doing either. I think the situation is
a rare corner case that only affects the unique solution I support.
The main thing for me is that I now know it is just the way the
hardware handles aggregates and not something that is caused by the
driver. So for me i don't think the benefit of doing a look ahead,
ensure AR_RxDone  for the frame and then peak at the rssi versus just
doing a max3 and a small comparison to get a close approximation is
worth the cost of coding and a possible increased delay in processing
frames. Perhaps there is a more elegant way for the former, but I am
still not certain if the effort to code it is worth the reward of an
rssi that may or may not be any more accurate then the max of the
individual chains. But hey, I am willing to be convince otherwise.

Thanks for all the help, it is much appreciated.

Daniel