9984 VHT

Tue Feb 7 04:39:28 PST 2017

Am 07.02.2017 um 13:14 schrieb Valo, Kalle:
> Ben Greear <greearb at candelatech.com> writes:
>
>> On 02/02/2017 10:42 AM, Sebastian Gottschall wrote:
>>> Am 02.02.2017 um 19:24 schrieb Ben Greear:
>>>> On 02/02/2017 08:18 AM, Ben Greear wrote:
>>>>> On 02/01/2017 10:45 AM, Sebastian Gottschall wrote:
>>>>>> Am 01.02.2017 um 17:48 schrieb Ben Greear:
>>>>>>> On 01/30/2017 02:28 AM, Sebastian Gottschall wrote:
>>>>>>>> Hello
>>>>>>>>
>>>>>>>> with recent 9984 firmares vht160 seem to crash the firmware itself for no reason i see.
>>>>>>>> is there any internal structure change in these newer firmwares we need to consider?
>>>>>>>> i also tested the even more recent firmware
>>>>>>>> firmware-5.bin_10.4-3.4-00068 from codeaurora. this one doesnt
>>>>>>>> crash but the vdev_start returns with a error
>>>>>>>>
>>>>>>>> i compared the more recent wmi headers from the qca drivers,
>>>>>>>> but wasnt able to find anything which could explain the
>>>>>>>> behaviour
>>>>>>>>
>>>>>>>> Sebastian
>>>>>>>>
>>>>>>>>
>>>>>>> Hello Sebastian,
>>>>>>>
>>>>>>> Could you share the hostapd/supplicant config file you are using?
>>>>>>>
>>>>>>> And, what kernel (or backports kernel) are you using?  I'd like to
>>>>>>> see how 160Mhz works on my firmware....
>>>>>> always state of art for sure
>>>>> Using a somewhat hacked 4.9.2+ kernel and my CT firmware, I get failure to start CAC:
>>>>>
>>>>> 1486052184.818710: Mode: IEEE 802.11a  Channel: 100  Frequency: 5500 MHz
>>>>> 1486052184.818714: DFS 8 channels required radar detection
>>>>> 1486052184.818717: DFS all channels available, (SKIP CAC): no
>>>>> 1486052184.818719: DFS 0 chans unavailable - choose other channel: no
>>>>> 1486052184.818722: vap0: interface state COUNTRY_UPDATE->DFS
>>>>> 1486052184.818725: DFS start CAC on 5500 MHz
>>>>> 1486052184.818733: vap0: DFS-CAC-START freq=5500 chan=100 sec_chan=1, width=2, seg0=114, seg1=0, cac_time=60s
>>>>> 1486052184.818737: nl80211: Start radar detection (CAC) 5500 MHz
>>>>> (ht_enabled=1, vht_enabled=1, bandwidth=160 MHz, cf1=5570 MHz,
>>>>> cf2=0 MHz)
>>>>> 1486052184.818742:   * freq=5500
>>>>> 1486052184.818745:   * vht_enabled=1
>>>>> 1486052184.818747:   * ht_enabled=1
>>>>> 1486052184.818749:   * bandwidth=160
>>>>> 1486052184.818751:   * channel_width=5
>>>>> 1486052184.818754:   * center_freq1=5570
>>>>> 1486052184.818756:   * center_freq2=0
>>>>> 1486052184.823437: nl80211: Failed to start radar detection: -16 (Device or resource busy)
>>>>> 1486052184.823444: DFS start_dfs_cac() failed, -1
>>>>>
>>>>>
>>>>> I'll go dig around to see if I can figure out why...
>>>> I hacked ath10k to enable radar detection on 160Mhz bandwidths. Now hostapd
>>>> starts.
>>>>
>>>> I can reproduce the FW failure.  It is because FW 3.3-25 release started asserting
>>>> if the freq2 was zero in VHT160 mode.  It seems to use both freq1 and freq2, and not
>>>> how the driver or linux seems to normally use them.
>>> its even worse. starting from 3.3 it uses freq2 instead of freq1.
>>> but i made a patch for it. but it still wont work. vdev_start still
>>> fails
>> Well it would have been helpful from the start to have known about this patch.
>>
>> Could you post it?
>>
>> Kalle:  Since the firmware API changed, how do you want to handle the differences here?
> The firmware API shouldn't change like that, but if it has I guess a
> firmware feature flag to enable a workaround in ath10k sounds like the
> easiest solution.
the more recent firmware have some new wmi services enabled which can be 
used as indicator as well.
right now i'm able to run it in vht160 mode enabled. my problem is just 
that the station which uses 9984 as well does only show vht80 in assoc 
state, but interface status shows vht160.
still inclear what has been changed. i just know that the new handling 
in the firmware has something todo with a workaround for buggy vht80 
clients for backward compatiblity. a similar change has been made
in hostapd. its not clear why qca moved this workaround to the firmware 
code itself, since hostapd can manage this too
>


-- 
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottschall at dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565