multi-antenna handling

multi-antenna handling

[Johannes Berg]

Hi,

This isn't really a proposal for a field definition, but more a usage
clarification that I'm seeking.

When we have multiple RX chains, it is often useful to know how much
power was received by each chain, and which chain(s) a frame was
received on.

Today, many drivers give the maximum power over all chains as a single
value, and some drivers give no antenna information while other drivers
(ab)use the (unitless) antenna index field (bit 11) as an antenna
bitmap.


I'm planning to modify this (in Linux) to include, where available,
antenna index & per-antenna signal information by duplicating the
radiotap namespace for each antenna, so that the header would, for
example, read as follows for a 3x3 devices:

 * ... TSF, Flags, Rate, Channel, ...
 * antenna signal: -40 dBm
 * antenna: 0
 * ... MCS, A-MPDU status, ...
 * antenna signal: -45 dBm
 * antenna: 1
 * antenna signal: -43 dBm
 * antenna: 2


Does this seem like sane behaviour? If so, do you think it would be
worthwhile describing it somewhere on the wiki?

johannes

Re: multi-antenna handling

[Johannes Berg]

On Mon, 2012-08-20 at 18:50 +0200, Johannes Berg wrote:

> I'm planning to modify this (in Linux) to include, where available,
> antenna index & per-antenna signal information by duplicating the
> radiotap namespace for each antenna, so that the header would, for
> example, read as follows for a 3x3 devices:
> 
>  * ... TSF, Flags, Rate, Channel, ...
>  * antenna signal: -40 dBm
>  * antenna: 0
>  * ... MCS, A-MPDU status, ...
>  * antenna signal: -45 dBm
>  * antenna: 1
>  * antenna signal: -43 dBm
>  * antenna: 2

FWIW, I've now implemented this in Linux (in mac80211), although I start
a new radiotap namespace for each antenna, separate from the first one,
so you'll see

 * any of: TSF, flags, rate, channel, MCS, a-mpdu, VHT, ...
(new radiotap namespace)
 * ant signal: -40 dBm
 * anntenna: 0
(new radiotap namespace)
 * ant signal: -45 dBm
 * anntenna: 1
... for however many antennas/chains there are.

johannes

Re: multi-antenna handling

[Guy Harris]

On Jul 8, 2013, at 1:59 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:

> FWIW, I've now implemented this in Linux (in mac80211), although I start
> a new radiotap namespace for each antenna, separate from the first one,
> so you'll see
> 
> * any of: TSF, flags, rate, channel, MCS, a-mpdu, VHT, ...
> (new radiotap namespace)
> * ant signal: -40 dBm
> * anntenna: 0
> (new radiotap namespace)
> * ant signal: -45 dBm
> * anntenna: 1
> ... for however many antennas/chains there are.

So is the idea that, in the first radiotap-namespace block, there will be no per-antenna information such as the antenna signal - the only per-antenna information will be in the subsequent namespace blocks?

Context: somebody asked on ask.wireshark.org about a capture from a D-Link router running OpenWRT; he claims that the router has 2 antennas, but the capture has 3 antenna signal strength values, the first of which is in the first radiotap namespace:

	http://ask.wireshark.org/questions/33994/why-there-are-3-rssi-values-in-the-radiotap-header-for-a-dual-antenna-wireless-card

Re: multi-antenna handling

[Johannes Berg]

On Tue, 2014-06-24 at 18:53 -0700, Guy Harris wrote:

> > FWIW, I've now implemented this in Linux (in mac80211), although I start
> > a new radiotap namespace for each antenna, separate from the first one,
> > so you'll see
> > 
> > * any of: TSF, flags, rate, channel, MCS, a-mpdu, VHT, ...
> > (new radiotap namespace)
> > * ant signal: -40 dBm
> > * anntenna: 0
> > (new radiotap namespace)
> > * ant signal: -45 dBm
> > * anntenna: 1
> > ... for however many antennas/chains there are.
> 
> So is the idea that, in the first radiotap-namespace block, there will
> be no per-antenna information such as the antenna signal - the only
> per-antenna information will be in the subsequent namespace blocks?

Exactly. It would have seemed strange to include the per-antenna fields
in general since the other data isn't specific to an antenna. It also
shows nicer in wireshark this way :)

> Context: somebody asked on ask.wireshark.org about a capture from a
> D-Link router running OpenWRT; he claims that the router has 2
> antennas, but the capture has 3 antenna signal strength values, the
> first of which is in the first radiotap namespace:
> 
> 	http://ask.wireshark.org/questions/33994/why-there-are-3-rssi-values-in-the-radiotap-header-for-a-dual-antenna-wireless-card

That's a bit strange - might be a driver quirk. The code I wrote has to
rely on the driver, adding Felix who might know more, I don't know how
ath9k works in this regard.

johannes

Re: multi-antenna handling

[Matteo Cypriani]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

Hi there,

On Wed, 25 Jun 2014 09:04:49 +0200, Johannes Berg <johannes-cdvu00un1Vhtvz77W8JrvQ@public.gmane.orgt>
wrote:
> > Context: somebody asked on ask.wireshark.org about a capture from a
> > D-Link router running OpenWRT; he claims that the router has 2
> > antennas, but the capture has 3 antenna signal strength values, the
> > first of which is in the first radiotap namespace:
> > 
> > 	http://ask.wireshark.org/questions/33994/why-there-are-3-rssi-values-in-the-radiotap-header-for-a-dual-antenna-wireless-card
> 
> That's a bit strange - might be a driver quirk. The code I wrote has to
> rely on the driver, adding Felix who might know more, I don't know how
> ath9k works in this regard.

I observed the same on TP-Link TL-WDR3500 (which is also ath9k-based), and
assumed the signal in the first namespace was an average of the two others.
Should I understand this may be a wrong assumption?

  Matteo

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: multi-antenna handling

[Johannes Berg]

On Wed, 2014-06-25 at 09:09 -0400, Matteo Cypriani wrote:

> I observed the same on TP-Link TL-WDR3500 (which is also ath9k-based), and
> assumed the signal in the first namespace was an average of the two others.
> Should I understand this may be a wrong assumption?

Ah, there's a value in the first part, without per-antenna information -
that's the max of the per-antenna values.

johannes

Re: multi-antenna handling

[Guy Harris]

On Jun 25, 2014, at 8:11 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:

> On Wed, 2014-06-25 at 09:09 -0400, Matteo Cypriani wrote:
> 
>> I observed the same on TP-Link TL-WDR3500 (which is also ath9k-based), and
>> assumed the signal in the first namespace was an average of the two others.
>> Should I understand this may be a wrong assumption?
> 
> Ah, there's a value in the first part, without per-antenna information -
> that's the max of the per-antenna values.

In the capture for the ask.wireshark.org question, frame 2 has -67 dBm in the first part, -68 dBm for antenna 0, and -73 dBm for antenna 1; I don't know what version of the kernel the machine in question is running, so I don't know what version of the ath9k driver it's running, but that's not a max or min or even an average.

Perhaps somebody needs to gently remind the maintainers of the ath9k driver not to put an extra signal value into the radiotap header, lest they confuse users.

The radiotap header dissects as:

Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Radiotap Header v0, Length 38
    Header revision: 0
    Header pad: 0
    Header length: 38
    Present flags
        .... .... .... .... .... .... .... ...1 = TSFT: True
        .... .... .... .... .... .... .... ..1. = Flags: True
        .... .... .... .... .... .... .... .1.. = Rate: True
        .... .... .... .... .... .... .... 1... = Channel: True
        .... .... .... .... .... .... ...0 .... = FHSS: False
        .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
        .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: False
        .... .... .... .... .... .... 0... .... = Lock Quality: False
        .... .... .... .... .... ...0 .... .... = TX Attenuation: False
        .... .... .... .... .... ..0. .... .... = dB TX Attenuation: False
        .... .... .... .... .... .0.. .... .... = dBm TX Power: False
        .... .... .... .... .... 0... .... .... = Antenna: False
        .... .... .... .... ...0 .... .... .... = dB Antenna Signal: False
        .... .... .... .... ..0. .... .... .... = dB Antenna Noise: False
        .... .... .... .... .1.. .... .... .... = RX flags: True
        .... .... .... .0.. .... .... .... .... = Channel+: False
        .... .... .... 0... .... .... .... .... = HT information: False
        .... .... ...0 .... .... .... .... .... = A-MPDU Status: False
        .... .... ..0. .... .... .... .... .... = VHT information: False
        ...0 0000 00.. .... .... .... .... .... = Reserved: 0x00000000
        ..1. .... .... .... .... .... .... .... = Radiotap NS next: True
        .0.. .... .... .... .... .... .... .... = Vendor NS next: False
        1... .... .... .... .... .... .... .... = Ext: True
        .... .... .... .... .... .... .... ...0 = TSFT: False
        .... .... .... .... .... .... .... ..0. = Flags: False
        .... .... .... .... .... .... .... .0.. = Rate: False
        .... .... .... .... .... .... .... 0... = Channel: False
        .... .... .... .... .... .... ...0 .... = FHSS: False
        .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
        .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: False
        .... .... .... .... .... .... 0... .... = Lock Quality: False
        .... .... .... .... .... ...0 .... .... = TX Attenuation: False
        .... .... .... .... .... ..0. .... .... = dB TX Attenuation: False
        .... .... .... .... .... .0.. .... .... = dBm TX Power: False
        .... .... .... .... .... 1... .... .... = Antenna: True
        .... .... .... .... ...0 .... .... .... = dB Antenna Signal: False
        .... .... .... .... ..0. .... .... .... = dB Antenna Noise: False
        .... .... .... .... .0.. .... .... .... = RX flags: False
        .... .... .... .0.. .... .... .... .... = Channel+: False
        .... .... .... 0... .... .... .... .... = HT information: False
        .... .... ...0 .... .... .... .... .... = A-MPDU Status: False
        .... .... ..0. .... .... .... .... .... = VHT information: False
        ...0 0000 00.. .... .... .... .... .... = Reserved: 0x00000000
        ..1. .... .... .... .... .... .... .... = Radiotap NS next: True
        .0.. .... .... .... .... .... .... .... = Vendor NS next: False
        1... .... .... .... .... .... .... .... = Ext: True
        .... .... .... .... .... .... .... ...0 = TSFT: False
        .... .... .... .... .... .... .... ..0. = Flags: False
        .... .... .... .... .... .... .... .0.. = Rate: False
        .... .... .... .... .... .... .... 0... = Channel: False
        .... .... .... .... .... .... ...0 .... = FHSS: False
        .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
        .... .... .... .... .... .... .0.. .... = dBm Antenna Noise: False
        .... .... .... .... .... .... 0... .... = Lock Quality: False
        .... .... .... .... .... ...0 .... .... = TX Attenuation: False
        .... .... .... .... .... ..0. .... .... = dB TX Attenuation: False
        .... .... .... .... .... .0.. .... .... = dBm TX Power: False
        .... .... .... .... .... 1... .... .... = Antenna: True
        .... .... .... .... ...0 .... .... .... = dB Antenna Signal: False
        .... .... .... .... ..0. .... .... .... = dB Antenna Noise: False
        .... .... .... .... .0.. .... .... .... = RX flags: False
        .... .... .... .0.. .... .... .... .... = Channel+: False
        .... .... .... 0... .... .... .... .... = HT information: False
        .... .... ...0 .... .... .... .... .... = A-MPDU Status: False
        .... .... ..0. .... .... .... .... .... = VHT information: False
        ...0 0000 00.. .... .... .... .... .... = Reserved: 0x00000000
        ..0. .... .... .... .... .... .... .... = Radiotap NS next: False
        .0.. .... .... .... .... .... .... .... = Vendor NS next: False
        0... .... .... .... .... .... .... .... = Ext: False
    MAC timestamp: 1789208778
    Flags: 0x10
        .... ...0 = CFP: False
        .... ..0. = Preamble: Long
        .... .0.. = WEP: False
        .... 0... = Fragmentation: False
        ...1 .... = FCS at end: True
        ..0. .... = Data Pad: False
        .0.. .... = Bad FCS: False
        0... .... = Short GI: False
    Data Rate: 1.0 Mb/s
    Channel frequency: 2412 [BG 1]
    Channel type: 802.11g (pure-g) (0x00c0)
        .... .... ...0 .... = Turbo: False
        .... .... ..0. .... = Complementary Code Keying (CCK): False
        .... .... .1.. .... = Orthogonal Frequency-Division Multiplexing (OFDM): True
        .... .... 1... .... = 2 GHz spectrum: True
        .... ...0 .... .... = 5 GHz spectrum: False
        .... ..0. .... .... = Passive: False
        .... .0.. .... .... = Dynamic CCK-OFDM: False
        .... 0... .... .... = Gaussian Frequency Shift Keying (GFSK): False
        ...0 .... .... .... = GSM (900MHz): False
        ..0. .... .... .... = Static Turbo: False
        .0.. .... .... .... = Half Rate Channel (10MHz Channel Width): False
        0... .... .... .... = Quarter Rate Channel (5MHz Channel Width): False
    SSI Signal: -67 dBm
    RX flags: 0x0000
        .... .... .... .... .... ..0. = Bad PLCP: False
    SSI Signal: -68 dBm
    Antenna: 0
    SSI Signal: -73 dBm
    Antenna: 1
IEEE 802.11 Null function (No data), Flags: ...P...TC

Re: multi-antenna handling

[Johannes Berg]

On Wed, 2014-06-25 at 19:07 -0700, Guy Harris wrote:
> On Jun 25, 2014, at 8:11 AM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> > On Wed, 2014-06-25 at 09:09 -0400, Matteo Cypriani wrote:
> > 
> >> I observed the same on TP-Link TL-WDR3500 (which is also ath9k-based), and
> >> assumed the signal in the first namespace was an average of the two others.
> >> Should I understand this may be a wrong assumption?
> > 
> > Ah, there's a value in the first part, without per-antenna information -
> > that's the max of the per-antenna values.
> 
> In the capture for the ask.wireshark.org question, frame 2 has -67 dBm in the first part, -68 dBm for antenna 0, and -73 dBm for antenna 1; I don't know what version of the kernel the machine in question is running, so I don't know what version of the ath9k driver it's running, but that's not a max or min or even an average.
> 
> Perhaps somebody needs to gently remind the maintainers of the ath9k
> driver not to put an extra signal value into the radiotap header, lest
> they confuse users.

I think that's likely my fault :-)

>     Present flags
>         .... .... .... .... .... .... .... ...1 = TSFT: True
>         .... .... .... .... .... .... .... ..1. = Flags: True
>         .... .... .... .... .... .... .... .1.. = Rate: True
>         .... .... .... .... .... .... .... 1... = Channel: True
>         .... .... .... .... .... .... ...0 .... = FHSS: False
>         .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
>         .... .... .... .... .... 0... .... .... = Antenna: False
[...]
>         .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
>         .... .... .... .... .... 1... .... .... = Antenna: True
>         .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
>         .... .... .... .... .... 1... .... .... = Antenna: True

>     SSI Signal: -67 dBm

>     SSI Signal: -68 dBm
>     Antenna: 0
>     SSI Signal: -73 dBm
>     Antenna: 1

We actually have one per-chain value, and one "overall" value, the
latter is what we report in the first radiotap namespace, the per-chain
ones in the latter namespaces that only have the signal and antenna
value (but obviously we could add anything else that made sense per
antenna)

Maybe we shouldn't be reporting the "overall" value? The calculation of
that seems to be driver dependent, our (the Intel) driver just takes the
max. If ath9k has a more specific calculation then I can see how that's
a bit confusing but OTOH it actually reports what much else of the stack
used for further work.

johannes

Re: multi-antenna handling

[Felix Fietkau]

On 2014-06-26 08:20, Johannes Berg wrote:
>>     Present flags
>>         .... .... .... .... .... .... .... ...1 = TSFT: True
>>         .... .... .... .... .... .... .... ..1. = Flags: True
>>         .... .... .... .... .... .... .... .1.. = Rate: True
>>         .... .... .... .... .... .... .... 1... = Channel: True
>>         .... .... .... .... .... .... ...0 .... = FHSS: False
>>         .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
>>         .... .... .... .... .... 0... .... .... = Antenna: False
> [...]
>>         .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
>>         .... .... .... .... .... 1... .... .... = Antenna: True
>>         .... .... .... .... .... .... ..1. .... = dBm Antenna Signal: True
>>         .... .... .... .... .... 1... .... .... = Antenna: True
> 
>>     SSI Signal: -67 dBm
> 
>>     SSI Signal: -68 dBm
>>     Antenna: 0
>>     SSI Signal: -73 dBm
>>     Antenna: 1
> 
> We actually have one per-chain value, and one "overall" value, the
> latter is what we report in the first radiotap namespace, the per-chain
> ones in the latter namespaces that only have the signal and antenna
> value (but obviously we could add anything else that made sense per
> antenna)
> 
> Maybe we shouldn't be reporting the "overall" value? The calculation of
> that seems to be driver dependent, our (the Intel) driver just takes the
> max. If ath9k has a more specific calculation then I can see how that's
> a bit confusing but OTOH it actually reports what much else of the stack
> used for further work.
ath9k does not calculate the combined signal strength itself, it simply
passes on what the hardware reports. I'm pretty sure the hardware
reports the effective signal strength after combining chain inputs (e.g.
via MRC).

- Felix

"Overall" and per-chain signal/noise values (was Re: multi-antenna handling)

[Guy Harris]

On Jun 25, 2014, at 11:20 PM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:

> We actually have one per-chain value, and one "overall" value, the
> latter is what we report in the first radiotap namespace, the per-chain
> ones in the latter namespaces that only have the signal and antenna
> value (but obviously we could add anything else that made sense per
> antenna)
> 
> Maybe we shouldn't be reporting the "overall" value? The calculation of
> that seems to be driver dependent, our (the Intel) driver just takes the
> max. If ath9k has a more specific calculation then I can see how that's
> a bit confusing but OTOH it actually reports what much else of the stack
> used for further work.

About 4 1/2 years later, the ath9k driver plus the mac80211 code appears to provide the "overall" strength plus per-antenna strengths, at least as of the 4.17.10 kernel, so I guess it's somewhat of a *de facto* standard that there's an "overall" value.

Given that, this is probably worth documenting - but not requiring, in case some adapter+driver combination doesn't supply it.

Presumably the description would be that:

	if you see a signal strength indication, and *don't* see an antenna number before the end of the header or a Radiotap Namespace field, it's an "overall" value;

	otherwise, it's a per-antenna value for the specified antenna.

Parsers must not assume that there will or won't be an "overall" value if there are per-antenna values.

The "overall" value for a multi-antenna receiver could be described as device-dependent, which might suggest that, unless you know the device, you shouldn't try to interpret it.

Re: "Overall" and per-chain signal/noise values (was Re: multi-antenna handling)

[Johannes Berg]

On Sun, 2018-12-30 at 13:47 -0800, Guy Harris wrote:
> On Jun 25, 2014, at 11:20 PM, Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> 
> > We actually have one per-chain value, and one "overall" value, the
> > latter is what we report in the first radiotap namespace, the per-chain
> > ones in the latter namespaces that only have the signal and antenna
> > value (but obviously we could add anything else that made sense per
> > antenna)
> > 
> > Maybe we shouldn't be reporting the "overall" value? The calculation of
> > that seems to be driver dependent, our (the Intel) driver just takes the
> > max. If ath9k has a more specific calculation then I can see how that's
> > a bit confusing but OTOH it actually reports what much else of the stack
> > used for further work.
> 
> About 4 1/2 years later, the ath9k driver plus the mac80211 code
> appears to provide the "overall" strength plus per-antenna strengths,
> at least as of the 4.17.10 kernel, so I guess it's somewhat of a *de
> facto* standard that there's an "overall" value.

I suppose you could argue that. The per-chain signals are actually
optional for drivers to provide, but the overall signal strength (which,
btw, isn't defined how this is derived from the per-chain signals if at
all) is more or less necessary for proper operation (roaming, ...)

> Given that, this is probably worth documenting - but not requiring, in
> case some adapter+driver combination doesn't supply it.
> 
> Presumably the description would be that:
> 
> 	if you see a signal strength indication, and *don't* see an
> antenna number before the end of the header or a Radiotap Namespace
> field, it's an "overall" value;
> 
> 	otherwise, it's a per-antenna value for the specified antenna.
> 
> Parsers must not assume that there will or won't be an "overall" value
> if there are per-antenna values.
> 
> The "overall" value for a multi-antenna receiver could be described as
> device-dependent, which might suggest that, unless you know the
> device, you shouldn't try to interpret it.

Makes sense. Want to update the github docs?

johannes