Re: ath10k stuck in mesh mode

[Michal Kazior]

On 22 November 2016 at 10:43, Matteo Grandi  wrote:
> Dear Bob, Michal, all
>
> I've finally managed to have a 80MHz channel bandwidth, thanks to your hint!
> The problem was related to the CRDA that even if it looks correctly
> installed, it actually doesn't work as supposed.
> I downloaded and recompiled the CRDA-3.18
> (http://drvbp1.linux-foundation.org/~mcgrof/rel-html/crda/) and set-up
> the regulatory domain.
> Notice that without setting up the reg. domain all the available
> channels have the "passive scanning" label because the CRDA prevent
> beaconing so mesh mode is not possible (maybe it's otherwise possible
> to operate in STA mode that doesn't require to send frames(?)).

STA can be allowed to transmit via beacon hints as far as I understand.


> Now I can have a mesh communication using 80MHz channel bandwidth, but
> MIMO still doesn't work.
> In fact the highest MCS reached was MCS9 that is the highest MCS with
> Single Spatial Stream, and I can't managed to have MIMO.

11n used mcs to imply nss. 11ac treats mcs and nss separately.
Therefore saying "MCS9 is 1SS" is incorrect. How are you checking
this? What device are you using for verifying?


> I played with the antennas position and distance, with the
> polarization and the presence or not of LOS, but by sniffing the
> transmissions I sow only MCS9 even if in the radiotap header field
> there are Antenna 0 and Antenna 1.
> However the radio information field report "Spatial streams: 1".
>
> Does anyone experienced something similar with the use of MIMO in mesh
> mode with the ath10k fw?
> I will thank any light you can shed to this!
> Thank you very much

You might want to debug peer_assoc commands sent to firmware. They may
be, for some reason, be requesting nss=1. Maybe sta_rc_update() isn't
properly updating peer in firmware. Driver debugs/dumps
(debug_mask=0xff) would be useful.


Michal

Re: ath10k stuck in mesh mode

[Matteo Grandi]

Dear Bob, Michal, all

I've finally managed to have a 80MHz channel bandwidth, thanks to your hint!
The problem was related to the CRDA that even if it looks correctly
installed, it actually doesn't work as supposed.
I downloaded and recompiled the CRDA-3.18
(http://drvbp1.linux-foundation.org/~mcgrof/rel-html/crda/) and set-up
the regulatory domain.
Notice that without setting up the reg. domain all the available
channels have the "passive scanning" label because the CRDA prevent
beaconing so mesh mode is not possible (maybe it's otherwise possible
to operate in STA mode that doesn't require to send frames(?)).

Now I can have a mesh communication using 80MHz channel bandwidth, but
MIMO still doesn't work.
In fact the highest MCS reached was MCS9 that is the highest MCS with
Single Spatial Stream, and I can't managed to have MIMO.
I played with the antennas position and distance, with the
polarization and the presence or not of LOS, but by sniffing the
transmissions I sow only MCS9 even if in the radiotap header field
there are Antenna 0 and Antenna 1.
However the radio information field report "Spatial streams: 1".

Does anyone experienced something similar with the use of MIMO in mesh
mode with the ath10k fw?
I will thank any light you can shed to this!
Thank you very much

Best Regards

Matteo

2016-11-21 13:53 GMT+01:00 Matteo Grandi :
> Yes, I noticed it, in fact it seems to be the reg. domain of the ath9k
> (there is also an ath9k card plugged on the same board).
> But it is in contrast with what I found in the syslog:
>
> Nov 21 07:53:23 MrProper kernel: [9.591563] ath: Regpair used: 0x3a
> Nov 21 07:53:23 MrProper kernel: [9.591573] cfg80211: Updating
> information on frequency 5180 MHz with regulatory rule:
> Nov 21 07:53:23 MrProper kernel: [9.591581] cfg80211: (514 KHz
> - 536 KHz @ 8 KHz), (N/A, 3000 mBm)
> [...]
> - 536 KHz @ 8 KHz), (N/A, 3000 mBm)
> Nov 21 07:53:23 MrProper kernel: [9.591654] cfg80211: Updating
> information on frequency 5300 MHz with regulatory rule:
> Nov 21 07:53:23 MrProper kernel: [9.591661] cfg80211: (514 KHz
> - 536 KHz @ 8 KHz), (N/A, 3000 mBm)
> Nov 21 07:53:23 MrProper kernel: [9.591668] cfg80211: Updating
> information on frequency 5320 MHz with regulatory rule:
> Nov 21 07:53:23 MrProper kernel: [9.591675] cfg80211: (514 KHz
> - 536 KHz @ 8 KHz), (N/A, 3000 mBm
>
> where there are @80MHz frequency slots.
>
> Is it possible that the system, showing all these different reg.
> domains from different cards, chose the most constrained one?
>
> 2016-11-21 11:53 GMT+01:00 Michal Kazior :
>> On 21 November 2016 at 10:46, Matteo Grandi  wrote:
>>> Dear Bob, Michal, all,
>>>
>>> I've just tried your advices (actually I already tried it following
>>> the wireless.wiki.kernel web pages) and I had a look at the syslog
>>> while I was typing the commands
>>> At the beginning I have this
>> [...]
>>> Other (hopefully) useful info:
>>> root@MrProper:~# iw reg get
>>> global
>>> country US: DFS-UNSET
>>> (2402 - 2472 @ 40), (3, 27), (N/A)
>>> (5170 - 5250 @ 40), (3, 17), (N/A)
>>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>>> (5735 - 5835 @ 40), (3, 30), (N/A)
>>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>>
>>> phy#2
>>> country US: DFS-UNSET
>>> (2402 - 2472 @ 40), (3, 27), (N/A)
>>> (5170 - 5250 @ 40), (3, 17), (N/A)
>>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>>> (5735 - 5835 @ 40), (3, 30), (N/A)
>>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>>
>>> phy#0
>>> country US: DFS-UNSET
>>> (2402 - 2472 @ 40), (3, 27), (N/A)
>>> (5170 - 5250 @ 40), (3, 17), (N/A)
>>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>>> (5735 - 5835 @ 40), (3, 30), (N/A)
>>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>>
>>> phy#1
>>> country US: DFS-UNSET
>>> (2402 - 2472 @ 40), (3, 27), (N/A)
>>> (5170 - 5250 @ 40), (3, 17), (N/A)
>>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>>> (5735 - 5835 @ 40), (3, 30), (N/A)
>>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>>[...]
>>>
>>> Checking on Internet I didn't find a working solution, and the data
>>> rate stucks to 120Mbps MCS7.
>>> For me it still a mistery, I hope in your help.
>>
>> Note the "@ 40" for all frequency ranges (except 60GHz band). Your
>> regulatory database seems to be limiting you to 40 MHz (it's probably
>> very old/ out of date). You'll need to update it to be able to use 80
>> MHz.
>>
>>
>> Michal

Re: ath10k stuck in mesh mode

[Matteo Grandi]

Yes, I noticed it, in fact it seems to be the reg. domain of the ath9k
(there is also an ath9k card plugged on the same board).
But it is in contrast with what I found in the syslog:

Nov 21 07:53:23 MrProper kernel: [9.591563] ath: Regpair used: 0x3a
Nov 21 07:53:23 MrProper kernel: [9.591573] cfg80211: Updating
information on frequency 5180 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.591581] cfg80211: (514 KHz
- 536 KHz @ 8 KHz), (N/A, 3000 mBm)
[...]
- 536 KHz @ 8 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.591654] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.591661] cfg80211: (514 KHz
- 536 KHz @ 8 KHz), (N/A, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.591668] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.591675] cfg80211: (514 KHz
- 536 KHz @ 8 KHz), (N/A, 3000 mBm

where there are @80MHz frequency slots.

Is it possible that the system, showing all these different reg.
domains from different cards, chose the most constrained one?

2016-11-21 11:53 GMT+01:00 Michal Kazior :
> On 21 November 2016 at 10:46, Matteo Grandi  wrote:
>> Dear Bob, Michal, all,
>>
>> I've just tried your advices (actually I already tried it following
>> the wireless.wiki.kernel web pages) and I had a look at the syslog
>> while I was typing the commands
>> At the beginning I have this
> [...]
>> Other (hopefully) useful info:
>> root@MrProper:~# iw reg get
>> global
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>
>> phy#2
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>
>> phy#0
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>
>> phy#1
>> country US: DFS-UNSET
>> (2402 - 2472 @ 40), (3, 27), (N/A)
>> (5170 - 5250 @ 40), (3, 17), (N/A)
>> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
>> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
>> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
>> (5735 - 5835 @ 40), (3, 30), (N/A)
>> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>>[...]
>>
>> Checking on Internet I didn't find a working solution, and the data
>> rate stucks to 120Mbps MCS7.
>> For me it still a mistery, I hope in your help.
>
> Note the "@ 40" for all frequency ranges (except 60GHz band). Your
> regulatory database seems to be limiting you to 40 MHz (it's probably
> very old/ out of date). You'll need to update it to be able to use 80
> MHz.
>
>
> Michal

Re: ath10k stuck in mesh mode

[Michal Kazior]

On 21 November 2016 at 10:46, Matteo Grandi  wrote:
> Dear Bob, Michal, all,
>
> I've just tried your advices (actually I already tried it following
> the wireless.wiki.kernel web pages) and I had a look at the syslog
> while I was typing the commands
> At the beginning I have this
[...]
> Other (hopefully) useful info:
> root@MrProper:~# iw reg get
> global
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#2
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#0
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>
> phy#1
> country US: DFS-UNSET
> (2402 - 2472 @ 40), (3, 27), (N/A)
> (5170 - 5250 @ 40), (3, 17), (N/A)
> (5250 - 5330 @ 40), (3, 20), (0 ms), DFS
> (5490 - 5600 @ 40), (3, 20), (0 ms), DFS
> (5650 - 5710 @ 40), (3, 20), (0 ms), DFS
> (5735 - 5835 @ 40), (3, 30), (N/A)
> (57240 - 63720 @ 2160), (N/A, 40), (N/A)
>[...]
>
> Checking on Internet I didn't find a working solution, and the data
> rate stucks to 120Mbps MCS7.
> For me it still a mistery, I hope in your help.

Note the "@ 40" for all frequency ranges (except 60GHz band). Your
regulatory database seems to be limiting you to 40 MHz (it's probably
very old/ out of date). You'll need to update it to be able to use 80
MHz.


Michal

Re: ath10k stuck in mesh mode

[Matteo Grandi]

Dear Bob, Michal, all,

I've just tried your advices (actually I already tried it following
the wireless.wiki.kernel web pages) and I had a look at the syslog
while I was typing the commands
At the beginning I have this
root@MrProper:~# tail -f -n 200 /var/log/syslog
Nov 21 07:53:23 MrProper kernel: [9.121882] cfg80211: Updating
information on frequency 5260 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121891] cfg80211: (525 KHz
- 533 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121900] cfg80211: Updating
information on frequency 5280 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121906] cfg80211: (525 KHz
- 533 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121913] cfg80211: Updating
information on frequency 5300 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121923] cfg80211: (525 KHz
- 533 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121931] cfg80211: Updating
information on frequency 5320 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121937] cfg80211: (525 KHz
- 533 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121946] cfg80211: Updating
information on frequency 5500 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121954] cfg80211: (549 KHz
- 560 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121963] cfg80211: Updating
information on frequency 5520 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121972] cfg80211: (549 KHz
- 560 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121982] cfg80211: Updating
information on frequency 5540 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.121990] cfg80211: (549 KHz
- 560 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.121997] cfg80211: Updating
information on frequency 5560 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122004] cfg80211: (549 KHz
- 560 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122012] cfg80211: Updating
information on frequency 5580 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122021] cfg80211: (549 KHz
- 560 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122029] cfg80211: Disabling
freq 5600 MHz for good
Nov 21 07:53:23 MrProper kernel: [9.122038] cfg80211: Disabling
freq 5620 MHz for good
Nov 21 07:53:23 MrProper kernel: [9.122044] cfg80211: Disabling
freq 5640 MHz for good
Nov 21 07:53:23 MrProper kernel: [9.122051] cfg80211: Updating
information on frequency 5660 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122058] cfg80211: (565 KHz
- 571 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122068] cfg80211: Updating
information on frequency 5680 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122077] cfg80211: (565 KHz
- 571 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122085] cfg80211: Updating
information on frequency 5700 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122094] cfg80211: (565 KHz
- 571 KHz @ 4 KHz), (300 mBi, 2000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122099] cfg80211: Disabling
freq 5720 MHz for good
Nov 21 07:53:23 MrProper kernel: [9.122110] cfg80211: Updating
information on frequency 5745 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122118] cfg80211: (5735000 KHz
- 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122125] cfg80211: Updating
information on frequency 5765 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122133] cfg80211: (5735000 KHz
- 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122141] cfg80211: Updating
information on frequency 5785 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122147] cfg80211: (5735000 KHz
- 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122156] cfg80211: Updating
information on frequency 5805 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122166] cfg80211: (5735000 KHz
- 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.122175] cfg80211: Updating
information on frequency 5825 MHz with regulatory rule:
Nov 21 07:53:23 MrProper kernel: [9.122184] cfg80211: (5735000 KHz
- 5835000 KHz @ 4 KHz), (300 mBi, 3000 mBm)
Nov 21 07:53:23 MrProper kernel: [9.487186] ath10k_pci
:07:00.0: qca988x hw2.0 (0x4100016c, 0x043222ff sub :) fw
10.2.4.70.58 fwapi 5 bdapi 1 htt-ver 2.1 wmi-op 5 htt-op 2 cal otp
max-sta 128 raw 1 hwcrypto 1 features no-p2p,raw-mode

Re: ath10k stuck in mesh mode

[Bob Copeland]

On Fri, Nov 18, 2016 at 10:43:06PM +0100, Matteo Grandi wrote:
> So the question is: who decide if use MIMO and higher MCS hopefully on
> 80MHz channel or not? Is the firmware? Is there a way to force the
> interface to use 80MHz and/or MIMO? (iw provide the possibility to
> choose between [HT20/HT40-/HT40+]).

You can specify the channel width like so:

iw dev wlan0 set freq 5745 80 5775
iw dev wlan0 mesh join mesh-vht

-- 
Bob Copeland %% http://bobcopeland.com/

ath10k stuck in mesh mode

[Matteo Grandi]

Hello,
I experimented a strange behavior during some data rate tests between
two wireless interfaces in mesh mode. The data rate stuck on 120Mbps
(iperf UDP test) and MCS7 that is the higher MCS of 80211n without
using MIMO, even when the channel is completely free.

My configuration:
two boards Gateworks Ventana 5410 running Ubuntu 14.04 kernel 3.14,
each board has two miniPCIe WiFi adapter Compex WLE600V5-27, 2
antennas each, ath10k drivers 802.11ac capabilities.
Backports-4.4.2
Firmware firmware-5.bin_10.2.4.70.58

I set up a mesh configuring, on each board, one interface as mesh
point, and I run an iperf UDP test, but even using channels free of
any other communication (48 and 149 in particular) the max data rate
achieved was 120Mbps on MCS7, and it stucked on that value and MIMO
was not in use despite the two antennas.
By sniffing the packets I discovered that only 802.11n was in use, and
I didn't notice nothing clearly strange in the syslog.
I tried on other channels but no MIMO nor 80MHz bandwidth (as expected
from the capabilities) was never  used (at most 40MHz with SGI). I
tried to have line of sight and play with the antennas position and
distance, but the data rate stuck on that value.
Note: I didn't the "@80" in any regulatoru domain by iw reg get (but
only @40), as it's using the reg. domain from ath9k (used on a
previous 802.11n miniPCIe adapter).
Note: I also tried to set up an AP and STA, and in that case MIMO was used.

So the question is: who decide if use MIMO and higher MCS hopefully on
80MHz channel or not? Is the firmware? Is there a way to force the
interface to use 80MHz and/or MIMO? (iw provide the possibility to
choose between [HT20/HT40-/HT40+]).

Any advice is the welcome, this project is part of my master thesis
and are weeks that I'm struggling with this problem.

Thank you

Matteo