[OpenWrt-Devel] 5GHz wifi is broken

[Sven Eckelmann]

On Saturday, 16 February 2019 22:36:18 CET Christian Lamparter wrote:
> @Ben can you please take a peek into your wave-1 firmware and check if the 
> mgmt_rate WMI (WMI_10X_VDEV_PARAM_MGMT_RATE) is supported, or if there is
> a bad interaction somewhere else?

I am using the same driver and ath10k-firmware-qca988x-ct on an OM5P-ACv2 with 
reboot-9393-gd0b45962ef. It seems to  work here for me with following 
configuration:

    config wifi-device 'radio0'
            option type 'mac80211'
            option channel '36'
            option hwmode '11a'
            option path 'pci0000:00/0000:00:00.0'
            option htmode 'VHT80'
            option disabled '0'
    
    config wifi-iface 'default_radio0'
            option device 'radio0'
            option network 'lan'
            option mode 'ap'
            option ssid 'OpenWrt'
            option encryption 'psk'
            option key 'supersecret'
    
    config wifi-iface 'default_radio2'
            option device 'radio0'
            option network 'lan'
            option mode 'ap'
            option ssid 'OpenWrt5'
            option encryption 'psk'
            option key 'supersecret2'
    
    config wifi-device 'radio1'
            option type 'mac80211'
            option channel '11'
            option hwmode '11g'
            option path 'platform/qca955x_wmac'
            option htmode 'HT20'
            option disabled '1'
    
    config wifi-iface 'default_radio1'
            option device 'radio1'
            option network 'lan'
            option mode 'ap'
            option ssid 'OpenWrt'
            option encryption 'none'

So it should work in theory. I personally (and some Freifunk Communities) need 
it more for 2.4GHz PHYs (Dakota). But also playing around with the rates for 
the QCA988X PHY (radio0) seems to work for me:

        list supported_rates '24000'
        list supported_rates '48000'
        list supported_rates '54000'
        list basic_rate '24000'
        list basic_rate '54000'

and the management rates (captured by a second device) are 24MBit/s.

So I would guess that it is something very specific (yeah, I know step 6 of 
"six stages of debugging": How did that ever work?). Having some way to 
reproduce it could be helpful - just do as Ben said to better understand the 
problem.

And we have a different user which also complained about something like this 
on Tp-Link Archer C60 V2 - but both radios were not working anymore. If this 
is true and related the it doesn't sound to me like this is strictly a 
ath10k(-ct) problem - one of the radios is ath9k. But who knows.

@Ben, the patch (or actually the whole series) is basically the upstream way 
to change the rate for management/broadcast/multicast frames. It is not using 
debugfs to communicate with the driver but just the events from mac80211. So 
it is less flexible in what you can do but works automatically. The broadcast 
multicast parts are in the kernel (and OpenWrt) for a while and these two 
patches just add the missing management rates part. They just wait for an 
BSS_CHANGED_BASIC_RATES event in ath10k_bss_info_changed and find the lowest 
basic rate + set this as management rate. Similar behavior to what ath9k & co 
are doing automatically with minstrel(_ht).

The implementation is a best effort implementation - if it fails to set the 
rate via WMI then it will print a warning and continue. I personally don't 
like how the control flow works in this patch. It just returns from 
ath10k_bss_info_changed even when some other parts (not yet existing in the 
current code) still might have to be run. But this is just how it was 
implemented and how Kalle Valo accepted it.

But the WMI part of the ath10k firmware (called by your debugfs interface and 
this upstream patch) is the same.

Kind regards,
	Sven
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20190218/96f0d548/attachment.sig>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel