[News] wifi: mt76: fix returned txpower for mt7921 and mt7925 (anyone want to test the patches?)

[morrownr]

Greetings,

Edit: I forgot to mention that this issue is cosmetic and that the adapters actually do use the correct txpower settings in accordance with wireless regulatory requirements. Showing 3 dBM is a cosmetic issue.

It appears that we are finally going to see a fix for txpower 3.00 dBm on various Mediatek drivers. The fix is in a series of 5 patches with the following title:

wifi: mt76: fix returned txpower for mt7921 and mt7925

You can view the patches at: https://patchwork.kernel.org/project/linux-wireless/list/

I think we have had at least one report of this problem per week for the last 2 years. I have no idea why Mediatek did not correct this problem.

@morrownr

[awaldram]

I think probably for marketing reasons. The mt792x.h limits all mt792x devices to 15 client max in AP, the bandwidth is also limited in some drivers ie on the 7922 series you can only achieve 80Mhz in AP mode despite its ability to support 160Mhz in Client mode.

Ive had to revert to a mt7612u on my iot network as I expect each Ap to support approx 20 client in use and 40+ in failure mode.

Probably worth making a note in your excellent 'usb' guides as its going to become more and more relevant as WiFi device multiply.

So for the popular client Mediatek chip-sets USB,SDIO or M2 you are limited to approx 15 clients in AP mode

via

#define MT792x_MAX_INTERFACES 4
#define MT792x_WTBL_SIZE 20
#define MT792x_WTBL_RESERVED (MT792x_WTBL_SIZE - 1) = 19
#define MT792x_WTBL_STA (MT792x_WTBL_RESERVED - MT792x_MAX_INTERFACES) 19-4 =15

so max Stations = 15

in https://github.com/openwrt/mt76/blob/master/mt792x.h

Horribly my espxx device didn't fail gracefully moving onto another AP, rather they got stuck on the maxed out AP without connection. Only way to recover the device was to reboot the maxed out AP

[morrownr]

Hi @awaldram

I have no problem adding this information to the appropriate documents here. I would prefer anything we add to be complete with information about max interfaces for other chips as well.

I see a couple of things to do. We can document it here and, probably as important, a well written message can be sent to linux-wireless in an effort to get the number changed or get an explanation for the current setting. Do you know how to send messages to linux-wireless?

[awaldram]

HI, I don't but would be surprised if the table can be altered as it is surely a hardware limitation rather than software. These devices are primarily designed as 'clients' and have many 'AP' features missing such as ACS and DFS adding additional memory to the devices to allow a larger Station table would increase the price and make them uncommercial besides gives you a few more clients than raspberry pis can deliver (10). I think it is more the user's requirement to see if their 'use' case falls inside the capability of the device rather than try and get the manufacturer to remediate hardware limits. for example I use a mt7925bm NanoPi R5C on my perimeter because I know i'll never have more then 5 'Wifi 7' clients here , my shed has a 7921u providing 2.4gb iot connectivity for the pir and door sensors on the alarm system. Whilst my main 'AP's' bpi4 and openwrt1 I utilise DFS to bring up 160Mhz 5ghz @ch128 .. the openwrt1 supports 'zero-wait-dfs' so brings it up immediately as a 2x2 (2402Mbs capability) whereas the bpi comes up as 3x3 (3603Mbs)) no 'client' designed adapter could hope to approach this but even more perverse the bpi4 is not even approaching it max capability for single channel bandwidth (6Gha,802.11Be 3x3 = 8647 Mbs capability) My point is Cost for any solution capability is a compromise VS cost. 802.11be supports 16 spatial streams but I doubt any manufacturer will ever deliver this same as we don't see any 8x8 802.11ax devices. In performance I can;t saturate either the openwrt1 or bpi4 but can easily flatline the mt7925 or mt7921u with multiple clients connected so I think 15 clients is reasonable for the processing capability of the devices, I find the mt7921u are much more stable on USB2 and in the 2.4Gb. Start pushing them to perform and they get a bit flaky.

…

On Fri, 21 Mar 2025 at 13:47, morrownr ***@***.***> wrote: Hi @awaldram <https://github.com/awaldram> I have no problem adding this information to the appropriate documents here. I would prefer anything we add to be complete with information about max interfaces for other chips as well. I see a couple of things to do. We can document it here and, probably as important, a well written message can be sent to linux-wireless in an effort to get the number changed or get an explanation for the current setting. Do you know how to send messages to linux-wireless? — Reply to this email directly, view it on GitHub <#576 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJEH66T7QFILZ64XGAW5VD2VQJ7TAVCNFSM6AAAAABW5ZDSYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBTGQYTQNBRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: morrownr]*morrownr* left a comment (morrownr/USB-WiFi#576) <#576 (comment)> Hi @awaldram <https://github.com/awaldram> I have no problem adding this information to the appropriate documents here. I would prefer anything we add to be complete with information about max interfaces for other chips as well. I see a couple of things to do. We can document it here and, probably as important, a well written message can be sent to linux-wireless in an effort to get the number changed or get an explanation for the current setting. Do you know how to send messages to linux-wireless? — Reply to this email directly, view it on GitHub <#576 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJEH66T7QFILZ64XGAW5VD2VQJ7TAVCNFSM6AAAAABW5ZDSYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBTGQYTQNBRG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[morrownr]

I wish this topic was in a new issue with an appropriate title as this topic comes up at times... not much but it does come up.

I don't but would be surprised if the table can be altered as it is surely a hardware limitation rather than software.

Not necessarily,

These devices are primarily designed as 'clients' and have many 'AP' features missing such as ACS and DFS...

I agree that USB WiFi adapters are primary designed as client devices. However, I have tested some mods temporarily to see if the hardware is capable of DFS AP mode and handling larger amounts of connections. All of the Mediatek and Realtek adapters that I have tested can support both. Now, these adapters do not have the ability to detect conflicts as required by DFS AP mode so we would wonder off into illegal territory so I won't go there. On the other hand, we are no violating any laws by upping the number of connections supported so I am all for testing this. If you want to test, I'll try to help. I don't have more than 15 clients to test so I am no help with doing it myself.

A couple of years ago, I remember a guy that stopped by here and was in more or the less same situation you were in. After some research and testing mine, I recommended a PAU08. I can check but I think that is a RT3070 chip. WiFi 4 only. He got one and reported back that things were working fine with over 32 IoT clients.

In performance I can;t saturate either the openwrt1 or bpi4 but can easily flatline the mt7925 or mt7921u with multiple clients connected so I think 15 clients is reasonable for the processing capability of the devices,

It, of course, depends on the throughput you need but the mt7921 and mt7925 have many times the p[rocessing power that the rt3070 does so that seems worth investigating.

Exactly which mt7921 adapter are you using and what computer is it plugged into?

And are you interested doing some testing?

[awaldram]

I didn't mean USB explicitly were client devices but mt792x irrelevant of interface. But by design. As to what I have in this series it a long list due to the excellent stability. At on stage I had 3 mt7921 I hung off a raspberry pi (2 off a usb3 hub unpowered). But in general usb power is an issue the above was fine on a 4mb pi4 but would stay up on an 8mb pi4. Currently I have 2 mt7921u and an m.2 mt7925 on a Nanopi R5c (openwrt 24.10rc5) You have to be careful with clean build running multiple adapters, I had kernel panics and all sort of issues with an mt7921u solution that turned out to be RTL drivers that if previously installed even though no RTL hardware was in use. My selection of mt7921u Edup Comfast Fenvri And some no-name clones I find they all perform the same with performance related to the ae gain not manufacturer, the 2dbi aerials give great coverage at close to medium distances whereas the 5dbi trials give worse close performance but better range . I'm not really in a position to do testing at the moment due to personal projects in flight. But if that changes I'll try recompiling a pi kernel with the max sta altered.

…

On Fri, 21 Mar 2025, 19:16 morrownr, ***@***.***> wrote: I wish this topic was in a new issue with an appropriate title as this topic comes up at times... not much but it does come up. I don't but would be surprised if the table can be altered as it is surely a hardware limitation rather than software. Not necessarily, These devices are primarily designed as 'clients' and have many 'AP' features missing such as ACS and DFS... I agree that USB WiFi adapters are primary designed as client devices. However, I have tested some mods temporarily to see if the hardware is capable of DFS AP mode and handling larger amounts of connections. All of the Mediatek and Realtek adapters that I have tested can support both. Now, these adapters do not have the ability to detect conflicts as required by DFS AP mode so we would wonder off into illegal territory so I won't go there. On the other hand, we are no violating any laws by upping the number of connections supported so I am all for testing this. If you want to test, I'll try to help. I don't have more than 15 clients to test so I am no help with doing it myself. A couple of years ago, I remember a guy that stopped by here and was in more or the less same situation you were in. After some research and testing mine, I recommended a PAU08. I can check but I think that is a RT3070 chip. WiFi 4 only. He got one and reported back that things were working fine with over 32 IoT clients. In performance I can;t saturate either the openwrt1 or bpi4 but can easily flatline the mt7925 or mt7921u with multiple clients connected so I think 15 clients is reasonable for the processing capability of the devices, It, of course, depends on the throughput you need but the mt7921 and mt7925 have many times the p[rocessing power that the rt3070 does so that seems worth investigating. Exactly which mt7921 adapter are you using and what computer is it plugged into? And are you interested doing some testing? — Reply to this email directly, view it on GitHub <#576 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJEH63WVFY2HUGPDDSL3BL2VRQSNAVCNFSM6AAAAABW5ZDSYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBUGI2DQNBYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: morrownr]*morrownr* left a comment (morrownr/USB-WiFi#576) <#576 (comment)> I wish this topic was in a new issue with an appropriate title as this topic comes up at times... not much but it does come up. I don't but would be surprised if the table can be altered as it is surely a hardware limitation rather than software. Not necessarily, These devices are primarily designed as 'clients' and have many 'AP' features missing such as ACS and DFS... I agree that USB WiFi adapters are primary designed as client devices. However, I have tested some mods temporarily to see if the hardware is capable of DFS AP mode and handling larger amounts of connections. All of the Mediatek and Realtek adapters that I have tested can support both. Now, these adapters do not have the ability to detect conflicts as required by DFS AP mode so we would wonder off into illegal territory so I won't go there. On the other hand, we are no violating any laws by upping the number of connections supported so I am all for testing this. If you want to test, I'll try to help. I don't have more than 15 clients to test so I am no help with doing it myself. A couple of years ago, I remember a guy that stopped by here and was in more or the less same situation you were in. After some research and testing mine, I recommended a PAU08. I can check but I think that is a RT3070 chip. WiFi 4 only. He got one and reported back that things were working fine with over 32 IoT clients. In performance I can;t saturate either the openwrt1 or bpi4 but can easily flatline the mt7925 or mt7921u with multiple clients connected so I think 15 clients is reasonable for the processing capability of the devices, It, of course, depends on the throughput you need but the mt7921 and mt7925 have many times the p[rocessing power that the rt3070 does so that seems worth investigating. Exactly which mt7921 adapter are you using and what computer is it plugged into? And are you interested doing some testing? — Reply to this email directly, view it on GitHub <#576 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJEH63WVFY2HUGPDDSL3BL2VRQSNAVCNFSM6AAAAABW5ZDSYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONBUGI2DQNBYGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[goraj]

Hi @awaldram / @morrownr,

I don't mean to hijack this ticket but would appreciate guidance if this patch would work for the following mt7921 (Nanopi R4S) using one of these Fevi USB adapters.
There seems to be an additional attempt to fix some of the issue (openwrt/mt76#954) that has not been merged to linux-firmware yet.

Kernel

root@router:~# uname -a
Linux router 6.6.78+ #1 SMP Fri Feb 28 14:14:56 UTC 2025 aarch64 GNU/Linux

Firmware

[   17.250765] mt7921u 8-1.2:1.0: WM Firmware Version: ____010000, Build Time: 20241106151045
[   17.427455] mt7921u 8-1.4:1.0: WM Firmware Version: ____010000, Build Time: 20241106151045

iw reg

root@router:~# iw reg get
global
country CN: DFS-FCC
	(2400 - 2483 @ 40), (N/A, 20), (N/A)
	(5150 - 5350 @ 80), (N/A, 20), (0 ms), DFS, AUTO-BW
	(5725 - 5850 @ 80), (N/A, 33), (N/A)
	(57240 - 59400 @ 2160), (N/A, 28), (N/A)
	(59400 - 63720 @ 2160), (N/A, 44), (N/A)
	(63720 - 65880 @ 2160), (N/A, 28), (N/A)

Distinct from some other mt7921 where people only see 3 dBM / 7 dBM I can retrieve the full txpowerlist but setting it above 3 dBm is not working. mt7921 eeprom

Failure to set txpower

root@router:~# ip link set phy1-ap0 down
root@router:~# iw dev phy1-ap0 set txpower fixed 20mBm
root@router:~# iwinfo phy1-ap0 txpowerlist
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
   3 dBm (   1 mW)
   4 dBm (   2 mW)
   5 dBm (   3 mW)
   6 dBm (   3 mW)
   7 dBm (   5 mW)
   8 dBm (   6 mW)
   9 dBm (   7 mW)
  10 dBm (  10 mW)
  11 dBm (  12 mW)
  12 dBm (  15 mW)
  13 dBm (  19 mW)
  14 dBm (  25 mW)
  15 dBm (  31 mW)
  16 dBm (  39 mW)
  17 dBm (  50 mW)
  18 dBm (  63 mW)
  19 dBm (  79 mW)
* 20 dBm ( 100 mW)
root@router:~# ip link set phy1-ap0 up
root@router:~# iwinfo phy1-ap0 txpowerlist
   0 dBm (   1 mW)
   1 dBm (   1 mW)
   2 dBm (   1 mW)
*  3 dBm (   1 mW)
   4 dBm (   2 mW)
   5 dBm (   3 mW)
   6 dBm (   3 mW)
   7 dBm (   5 mW)
   8 dBm (   6 mW)
   9 dBm (   7 mW)
  10 dBm (  10 mW)
  11 dBm (  12 mW)
  12 dBm (  15 mW)
  13 dBm (  19 mW)
  14 dBm (  25 mW)
  15 dBm (  31 mW)
  16 dBm (  39 mW)
  17 dBm (  50 mW)
  18 dBm (  63 mW)
  19 dBm (  79 mW)
  20 dBm ( 100 mW)

root@router:~# lsmod |grep mt
mt7921u                16384  0
mt792x_usb             12288  1 mt7921u
mt76x2u                24576  0
mt76x2_common          20480  1 mt76x2u
mt76x02_usb            20480  1 mt76x2u
mt76x02_lib            65536  3 mt76x02_usb,mt76x2u,mt76x2_common
mt76_usb               32768  4 mt792x_usb,mt76x02_usb,mt76x2u,mt7921u
mt7921e                16384  0
mt7921_common          61440  2 mt7921e,mt7921u
mt792x_lib             40960  3 mt7921e,mt7921_common,mt7921u
mt76_connac_lib        53248  4 mt792x_lib,mt7921e,mt7921_common,mt7921u
mt76                   81920  11 mt792x_lib,mt792x_usb,mt7921e,mt76_usb,mt76x02_lib,mt76x02_usb,mt7921_common,mt76x2u,mt76x2_common,mt76_connac_lib,mt7921u
mac80211              860160  7 mt792x_lib,mt76,mt76x02_lib,mt76x02_usb,mt7921_common,mt76x2u,mt76_connac_lib
cfg80211              790528  14 rtl8812au,mt76,mt76x02_lib,brcmfmac,rtl8822bu,iwlwifi,rtl8821CU,mac80211,rtl8822cs,mt76x02_usb,mt7921_common,mt76x2_common,mt76_connac_lib,rtl8822ce

/sys/kernel/debug/ieee80211/phy0/mt76/eeprom is empty.

[morrownr]

@awaldram

I'm not really in a position to do testing at the moment due to personal projects in flight. But if that changes I'll try recompiling a pi kernel with the max sta altered.

If you find that modifying max sta works, I can send in a patch to see if Mediatek will accept it. No hurry.

[morrownr]

@goraj

There seems to be an additional attempt to fix some of the issue (openwrt/mt76#954) that has not been merged to linux-firmware

That is the same effort.

Distinct from some other mt7921 where people only see 3 dBM / 7 dBM I can retrieve the full txpowerlist but setting it above 3 dBm is not working. mt7921 eeprom

Please understand that this 3 dBm issue is cosmetic only. Your adapters are actually running at proper twpower settings. The code that needs work is the code that allows iw to read the settings properly and to allow iw to set txpower properly.

[goraj]

Thank you @morrownr

Please understand that this 3 dBm issue is cosmetic only. Your adapters are actually running at proper twpower settings. The code that needs work is the code that allows iw to read the settings properly and to allow iw to set txpower properly.

Curious why iwinfo phy1-ap0 txpowerlist would return 20 dBm after setting tx power but after spinning the device up a subsequent call shows it reverted back to 3 dBm? If it's purely cosmetic I'd assume both cases should return 3 dBm?

[morrownr]

Curious why iwinfo phy1-ap0 txpowerlist would return 20 dBm after setting tx power...

I think iwinfo is designed to work with wireless extentions (WEXT) which is long since depreciated so it it best to use the modern iw utility.

The code in the driver does not yet actually allow iw to set txpower if memory serves me correctly. It has been a while but there is an issue here where a deep dive was made and an individual used debug to go in and see what was actually going on. What was confirmed was that the driver is setting txpower at the max txpower allowed by regdb, which can vary depending on your country. I contend that there are situations where we want to reduce txpower to less than max so it would be nice to be able to reduce txpower. Hopefully the code for iw to show the proper txpower and the ability to change txpower is coming. Three patches to get ready for this went into kernel 6.15 this week. Until the remaining patches go in, we need to be patient.

Are you seeing a problem with range?

[goraj]

Are you seeing a problem with range?
I do - but it could be misinterpretation from my side.
I've ran an experiment setting txpower from 100 to 2500 while monitoring dBm with my mobile phone and see absolutely no change.

eg:

ifconfig  phy1-ap0 down
iw dev phy1-ap0 set txpower fixed {100, ..., 2500}
ifconfig  phy1-ap0 up

[morrownr]

ifconfig phy1-ap0 down

ifconfig is depreciated. Please use ip and iw as they are the modern tools to use.

iw dev phy1-ap0 set txpower fixed {100, ..., 2500}

I maybe have not been clear earlier. You are not setting txpower. We are trying to get that capability in the driver.

I've ran an experiment setting txpower from 100 to 2500 while monitoring dBm with my mobile phone and see absolutely no change.

This is normal for now. You have no capability to set txpower.

If you think there is a problem with range, we can work that. I'd need to know the details of your setup.

[morrownr]

Here is the documentation for iw:

https://wireless.docs.kernel.org/en/latest/en/users/documentation/iw.html

I can to be out of my office this afternoon but if you have trouble finding the documentation for ip, let me know and I will help.

[goraj]

Thank you, I'll experiment a bit more.
Maybe the prior TP-Link devices (which worked much better) was due to their antenna.
I've ordered some different adapters with better gain and will see if this resolves the issues.