9984 VHT

Thu Feb 2 12:28:33 PST 2017

Am 02.02.2017 um 20:32 schrieb Ben Greear:
> On 02/02/2017 11:29 AM, Sebastian Gottschall wrote:
>> Am 02.02.2017 um 20:18 schrieb Ben Greear:
>>> On 02/02/2017 11:08 AM, Sebastian Gottschall wrote:
>>>> Am 02.02.2017 um 20:05 schrieb Ben Greear:
>>>>> 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.
>>>> i wasnt sure about it at that time. since it did not work
>>>>>
>>>>> Could you post it?
>>>> --- wmi.c       (revision 3267)
>>>> +++ wmi.c       (working copy)
>>>> @@ -1637,11 +1637,12 @@
>>>>                 flags |= WMI_CHAN_FLAG_DFS;
>>>>
>>>>         ch->mhz = __cpu_to_le32(arg->freq);
>>>> +       ch->band_center_freq2 = 0;
>>>>         ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
>>>>         if (arg->mode == MODE_11AC_VHT80_80)
>>>>                 ch->band_center_freq2 = 
>>>> __cpu_to_le32(arg->band_center_freq2);
>>>> -       else
>>>> -               ch->band_center_freq2 = 0;
>>>> +       if (arg->mode == MODE_11AC_VHT160)
>>>> +               ch->band_center_freq2 = 
>>>> __cpu_to_le32(arg->band_center_freq1);
>>>>         ch->min_power = arg->min_power;
>>>>         ch->max_power = arg->max_power;
>>>>         ch->reg_power = arg->max_reg_power;
>>>
>>> That would not appear to work with my FW, but, my FW's comments 
>>> don't seem to match
>>> it's code, so I am not sure where all the bugs lie.  Maybe re-check 
>>> the source of this
>>> patch above to make sure you got it right?
>> its right if you already applied the vht160 patch which is in git 
>> already since a while (wireless-next)
>> in openwrt the staging tree of nbd contains the same source which 
>> which fits to this patch
>> but if it wont apply to you you have to update your whole wireless 
>> source to latest version since you did not have the required vht160 
>> patches
>
> I mean the content of the patch is invalid, not a merge issue.
>
> Try setting freq1 to center-freq of the primary 80Mhz channel.
> And set freq2 to center-freq of the 160Mhz channel
so something like  that?

+       if (arg->mode == MODE_11AC_VHT160)  {
+               ch->band_center_freq1 = __cpu_to_le32(arg->freq);
+               ch->band_center_freq2 = 
__cpu_to_le32(arg->band_center_freq1);
+       }


Thanks,
> Ben
>
>
>


-- 
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