[ath9k-devel] Chip glitch for RSSI value ?

[ath9k-devel] Chip glitch for RSSI value ?

[Christophe Prévotaux]

Sometimes it seems the ath9k series chips (at least some of them ) do not report RSSI for some frames, is this a known chip glitch ?

-- 
Christophe Pr?votaux
Email: c.prevotaux at rural-networks.com

[ath9k-devel] Chip glitch for RSSI value ?

[Till Wollenberg]

Hi!

* On 11.12.2014, 17:14 Christophe Pr?votaux wrote:
> Sometimes it seems the ath9k series chips (at least some of them ) do not report RSSI for some frames, is this a known chip glitch ?

I don't know if it is a chip glitch, but I can confirm the observation. I have a 
dataset of 2.05 billion frames received with AR9280 cards in monitor mode. I 
used ath9k from OpenWRT 12.09 (kernel 3.3.8).

Out of these frames, about 2% do not carry signal/noise information. Also, for 
about 0.4% of all frames a signal level of 0dBm or above is reported, which is 
unlikely to be correct.

Best regards
Till

-- 
Dipl.-Inf. Till Wollenberg
University of Rostock, Faculty of CS and EE
Institute of Computer Science
18055 Rostock, Germany
Tel.: +49 (0)381 498-7507

[ath9k-devel] Chip glitch for RSSI value ?

[Adrian Chadd]

Hi,

I _think_ that the only valid timestamp/rssi is is the final frame in
an aggregate, not the intermediary frames. Did you correlate your
checking with whether it was an aggregate or not, and if it's an
aggregate, whether it's first, middle or final?



-adrian


On 11 December 2014 at 10:19, Till Wollenberg
<till.wollenberg@uni-rostock.de> wrote:
> Hi!
>
> * On 11.12.2014, 17:14 Christophe Pr?votaux wrote:
>> Sometimes it seems the ath9k series chips (at least some of them ) do not report RSSI for some frames, is this a known chip glitch ?
>
> I don't know if it is a chip glitch, but I can confirm the observation. I have a
> dataset of 2.05 billion frames received with AR9280 cards in monitor mode. I
> used ath9k from OpenWRT 12.09 (kernel 3.3.8).
>
> Out of these frames, about 2% do not carry signal/noise information. Also, for
> about 0.4% of all frames a signal level of 0dBm or above is reported, which is
> unlikely to be correct.
>
> Best regards
> Till
>
> --
> Dipl.-Inf. Till Wollenberg
> University of Rostock, Faculty of CS and EE
> Institute of Computer Science
> 18055 Rostock, Germany
> Tel.: +49 (0)381 498-7507
>
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel

[ath9k-devel] Chip glitch for RSSI value ?

[Till Wollenberg]

Hi!

* On 12.12.2014 00:05 Adrian Chadd wrote:
> I _think_ that the only valid timestamp/rssi is is the final frame in
> an aggregate, not the intermediary frames. Did you correlate your
> checking with whether it was an aggregate or not, and if it's an
> aggregate, whether it's first, middle or final?

Thank you for pointing this out! I checked some of the frames without signal 
information in my dataset. In all cases, these frames belong to a row of frames 
with identical source and destination addresses, and more important, with 
identical MAC timestamp.

However, in some cases the first frame of a row carries a signal value while all 
others do not, and in some cases the very last frame carries a signal value 
while all others do not.

There are also cases with a row of frames having identical MAC timestamps, but 
no frame has a signal value.

It seems aggregated frames are de-aggregated somewhere on the chip or in the 
driver before they appear on the monitor mode interface. Do you know if it is 
possible (at least in theory) to pass A-MPDU and/or A-MSDU frames "as they are", 
i.e. without de-aggregation, up to a monitor mode interface?


Best regards
Till

[ath9k-devel] Chip glitch for RSSI value ?

[Adrian Chadd]

On 15 December 2014 at 08:40, Till Wollenberg
<till.wollenberg@uni-rostock.de> wrote:
> Hi!
>
> * On 12.12.2014 00:05 Adrian Chadd wrote:
>>
>> I _think_ that the only valid timestamp/rssi is is the final frame in
>> an aggregate, not the intermediary frames. Did you correlate your
>> checking with whether it was an aggregate or not, and if it's an
>> aggregate, whether it's first, middle or final?
>
>
> Thank you for pointing this out! I checked some of the frames without signal
> information in my dataset. In all cases, these frames belong to a row of
> frames with identical source and destination addresses, and more important,
> with identical MAC timestamp.
>
> However, in some cases the first frame of a row carries a signal value while
> all others do not, and in some cases the very last frame carries a signal
> value while all others do not.
>
> There are also cases with a row of frames having identical MAC timestamps,
> but no frame has a signal value.

Hm, interesting. Ok, so can you paste examples of these? I'd be
interested in the state of the PHY errors and other potential causes
of error.

> It seems aggregated frames are de-aggregated somewhere on the chip or in the
> driver before they appear on the monitor mode interface. Do you know if it
> is possible (at least in theory) to pass A-MPDU and/or A-MSDU frames "as
> they are", i.e. without de-aggregation, up to a monitor mode interface?

I don't think there's a way to disable the A-MPDU logic. I can
double-check with the hardware contacts I have, but I'm still trying
to finish chasing up the last couple of wtf's from the AR9380. :P



-adrian