Different how?
993 mW in 2.4 GHz is right at 1W which is 30 dBm, just like I said. 541 mW from 5.18-5.24 GHz (which is UNII-1) is 27 dBm (every ~3 dBm halves the power) - again, just like I stated. Finally, 995 mW from 5.745-5.825 GHz (which is UNII-3) is again right at 30 dBM - just as I stated above.
I actually forgot you posted that
It's not OpenWrt limiting the TX power. The mt76 driver uses the max TX power listed in the wireless-regdb database https://wireless.wiki.kernel.org/en/developers/regulatory/wireless-regdb .
For USA UNII-1 bands, it's mentioned at (the url points to the db.txt in the wireless-regdb git tag master-2023-09-01) https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt?id=991b1ef696b7a034a5bf001cf31ab7735888c6e1#n1785
For Canada, it's mentioned at https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-regdb.git/tree/db.txt?id=991b1ef696b7a034a5bf001cf31ab7735888c6e1#n348
I haven't bisected to when it happened, but OpenWrt previously (within last year or so) allowed higher UNII-1 txpower on my RT3200 as well as other devices I've noticed this limitation cropping up on (ipq806x targets).
Thanks for the pointer to the wireless-regdb. Looks like it is far behind the times. The FCC has allowed 30 dBm in UNII-1 since 2014: https://www.federalregister.gov/documents/2014/05/01/2014-09279/unlicensed-national-information-infrastructure-u-nii-devices-in-the-5-ghz-band
So... what, if anything, can be done about it?
There are instructions on to how to propose updates to the wireless-regdb database at https://wireless.wiki.kernel.org/en/developers/regulatory/wireless-regdb#sending_updates_to_the_regulatory_database
Patches or well explained change requests (both with pointers to the official regulatory rules/ rule changes of your country!) will nevertheless be processed, it may take a few weeks, but it will be attended nevertheless (in bulk).
The better your explanation, the easier you make it for them to verify it with the regulatory bodies of your country, the less you 'waste' the time of the reviewers, the better your chances for (relatively) quick processing.
Reviving the dead. I stumbled on some history of this topic here: https://patchwork.kernel.org/project/linux-wireless/patch/1437622380-4154-5-git-send-email-wens@csie.org/#14634341
The US FCC increased the maximum conducted transmission power for the U-NII-1 (5150 ~ 5250 MHz; channels 36 ~ 48) band to 30 dBm or 1 W for master devices and 24 dBm or 250 mW for mobile/portable devices in 2014. See FCC KDB 905462 D06 and https://transition.fcc.gov/bureaus/oet/ea/presentations/files/oct14/51-New-Rules-for-UNII-Bands,-Oct-2014-TN.pdf.
The wireless-regdb has no mechanism to distinguish between AP and client mode, therefore it restricted US transmit power to 250 mW for both AP's and clients. The wireless-regdb maintainers further decided to conservatively round 250 mW down to 23 dBm for the U-NII-1 band only, which is not consistent with implementation by wireless-regdb of the same 250 mW limit for US U-NII-2 as 24 dBm.
It seems necessarily up to the firmware, not wireless-regdb, to allow US U-NII-1 transmit power up to 30 dBm depending on whether the firmware is operating the device as an AP and not a client. There are numerous examples of OEM firmware legally allowing US U-NII-1 transmit power up to 30 dBm in AP mode. OpenWrt firmware does not. Instead, OpenWrt reduces allowed US U-NII-1 AP transmit power by a whopping 79% (30 dbm to 23 dBm) across the board, because it defaults to the wireless-regdb. If OpenWrt is ever to support US U-NII-1 AP transmit power of 30 dBm, it seems this must be addressed in OpenWrt. It's not clear how this could reasonably be "fixed" in wireless-regdb without restructuring wireless-regdb to distinguish between operating modes, in which case changes to firmware, including OpenWrt, would still be required to make use of it.
It would also be nice if the wireless-regdb could consistently implement a US 250 mW limit as 24 dBm. Slapping a 17% reduction (23 dBm vs. 24 dBm for a 250 mW limit) on U-NII-1 only is just strange, but that doesn't seem appropriate to address in OpenWrt when this more minor issue is with the wireless-regdb.
Don't expect that to be changed for OpenWrt. The relevant regulatory bodies insist that the maximum values are obeyed and not user-changeable (yes, even allowing users to select their country is already frowned upon and not accepted for new devices seeking certification), so widening the permissible options beyond the minimum that's always possible is a very slippery slope. But there is another issue, doing this would essentially neuter the values from wireless-regdb and force OpenWrt to become the final arbiter to decide what limits are permissible and which aren't, for every country of the world, that's not likely to happen - you want this to be done via wireless-regdb. Why can Cisco do that, because they have the staff and business incentive to so do for the regions they're selling to - OpenWrt can't (wireless-regdb tries to do this, for everyone in the linux ecosystem (and beyond)).
We already -regularly- have users who are looking for the most permissible countries around to game the system - OpenWrt really can't make that any easier. Lawsuit- and project closure in 3-2-1-gone.
Would there be reasons to structurally overhaul wireless-regdb, maybe - but that's not going to happen via OpenWrt, that's something you need to discuss upstream (linux-wireless@v.k.o/ mainline); desire for this exists, but it's a major can of worms.
Accordingly I do not think anyone will attend https://github.com/openwrt/openwrt/issues/15032 according to your intentions, it's something that needs to be solved mainline, via the linux-wireless developers.
Disclaimer: I'm not an OpenWrt developer and can't speak for the project, the above is just my own interpretation of the situation and personal opinion.
I don't disagree there are no great solutions for this.
If nothing else, the next person to notice they've lost 80% of their U-NII-1 transmit power after flashing OpenWrt may find the actual reason why in this thread - versus hardware limitation, antenna gain, FCC certification, fill-in-the-blank etc. red herrings.
