Re: wifi: mt76: mt7915: remove VHT160 capability on MT7915?

2023-08-20 Thread Felix Baumann
Am 20. August 2023 04:01:55 MESZ schrieb Thomas Walker :
>Doing a little more reading and guessing that this is related to
>https://forum.openwrt.org/t/802-11ax-worse-than-802-11ac-with-mt76-driver/126466/408?
>
>Giving it (VHT80 and explicitly enabling the coloring/beam forming ax
>bits) a try.  I'm not really one to be running iperf against every
>config change, nor do I have more than 1 or 2 ax clients so maybe I
>simply missed the potential perf impact?  I just noticed when the
>config I'd been using for 6+ months failed in a way that didn't
>provide much of a useful error message and required bisecting to hunt
>down.
>
>(And a likely inconsequential error in my initial report, the device
>is an RB03, not RB01.)
>
>___
>openwrt-devel mailing list
>openwrt-devel@lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-devel

This might've been fixed already, but not in 23 rc, yet.
https://github.com/openwrt/mt76/commit/bb3937d5c3e0b13c0d08747ec0fc9726fb4fd870


Regards
Felix Baumann

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Re: wifi: mt76: mt7915: remove VHT160 capability on MT7915?

2023-08-19 Thread Thomas Walker
Doing a little more reading and guessing that this is related to
https://forum.openwrt.org/t/802-11ax-worse-than-802-11ac-with-mt76-driver/126466/408?

Giving it (VHT80 and explicitly enabling the coloring/beam forming ax
bits) a try.  I'm not really one to be running iperf against every
config change, nor do I have more than 1 or 2 ax clients so maybe I
simply missed the potential perf impact?  I just noticed when the
config I'd been using for 6+ months failed in a way that didn't
provide much of a useful error message and required bisecting to hunt
down.

(And a likely inconsequential error in my initial report, the device
is an RB03, not RB01.)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


wifi: mt76: mt7915: remove VHT160 capability on MT7915?

2023-08-19 Thread Thomas Walker
(Apologies Felix, as you're probably getting this twice because I'm an
idiot and didn't set gmail to plain text.)

Hi all,

I've been running the openwrt-23.05 branch on a Redmi AX6S (RB01) for
maybe 6 months now without issue.  I build my own to include custom
config, etc and usually update every week or so.  But I've been out of
town for a month and didn't update while I was away.  When I did
update a few days ago, my 5G wifi failed to come up with:

Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: interface
state HT_SCAN->DFS
Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: DFS-CAC-START
freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Aug 19 17:42:09 2023 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: interface
state DFS->DISABLED

Granted, the output before wasn't exactly pretty, but it worked (I
presume the warnings are because these aren't DFS channels, but...):

Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: interface
state HT_SCAN->DFS
Sat Aug 19 17:42:09 2023 daemon.notice hostapd: wl1-ap0: DFS-CAC-START
freq=5180 chan=36 sec_chan=1, width=2, seg0=50, seg1=0, cac_time=60s
Sat Aug 19 17:52:01 2023 daemon.notice hostapd: wl1-ap0:
DFS-CAC-COMPLETED success=1 freq=5180 ht_enabled=0 chan_offset=0
chan_width=5 cf1=5250 cf2=0
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5180 MHz
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5200 MHz
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5220 MHz
Sat Aug 19 17:52:01 2023 daemon.warn hostapd: Can't set DFS state for
freq 5240 MHz
Sat Aug 19 17:52:02 2023 daemon.notice hostapd: wl1-ap0: interface
state DFS->ENABLED

I spent a bit of time bisecting the issue and it came down to:

commit 063641f8cf7990731919b950c1bf9eb15d1e74c9
Author: Felix Fietkau 
Date:   Fri Jul 14 11:20:30 2023 +0200

mt76: update to the latest version

bb3937d5c3e0 wifi: mt76: mt7915: remove VHT160 capability on MT7915

Signed-off-by: Felix Fietkau 

Which corresponds to (in https://github.com/openwrt/mt76):

commit bb3937d5c3e0b13c0d08747ec0fc9726fb4fd870
Author: Felix Fietkau 
Date:   Fri Jul 14 10:57:15 2023 +0200

    wifi: mt76: mt7915: remove VHT160 capability on MT7915

The IEEE80211_VHT_CAP_EXT_NSS_BW value already indicates support
for half-NSS
160 MHz support, so it is wrong to also advertise full 160 MHz support.

Fixes: c2f73eacee3b ("wifi: mt76: mt7915: add back 160MHz channel
width support for MT7915")
Signed-off-by: Felix Fietkau 

Yes, I've been (up until now) successfully using VHT160 on channel 36
as it is the only reliable 160mhz band available in the US that isn't
subject to DFS (and where I'm located, DFS strikes are almost
constant).  Reverting this patch (or choosing VHT80 or lower) does
indeed work.  I must admit, I'm not well versed in various wireless
extensions or what 'IEEE80211_VHT_CAP_EXT_NSS_BW' or 'half-NSS'
entails (I do kernel stuff for a living, but datacenter stuff, so my
wireless knowledge is very limited), but clearly something broke for
me here.  Relevant radio section is below:

config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11a'
option path '1a143000.pcie/pci:00/:00:00.0/:01:00.0'
option cell_density '0'
# best channel for our locality (104 keeps getting DFS strikes)
option channel '36'
# the two ranges that support 160mhz
# 149-177 should, but is missing channels in regdb and turns into 80mhz
# 
https://forum.openwrt.org/t/5-ghz-wlan-craps-out-upon-radar-detection-start-dfs-cac-failed/71018/15
# in practice, this means we always stay at 36 (no DFS).  But
so does everyone else.
option channels '36-64 100-128'
option country 'US'
option htmode 'VHT160'

(the 149-177 regdb comment is likely dated, but I haven't tried it
again in recent history)

Is there something that I'm missing here that would allow VHT160 to
work with this patch?

Thank you very much!
(I've been an openwrt user for nearly a decade now and am so happy
that there is a reliable, stable alternative to the crap OEM
firmware... Keep up the great work!)

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel