mt76 TX power not working in multiple chipsets (mt7610, mt7613, mt7615, mt7603) #633

dmsza · 2021-12-05T11:35:44Z

Just looking at the bug reports here and in the OpenWRT defects repository, it is clear that for various mt76 chipsets the TX power is simply not working.

I myself am experimenting two issues with OpenWRT and mt76 drivers:

With mt7613 on an TP-Link Archer C6 v3 with OpenWRT where TX power is set to maximum and cannot be changed (details in the OpenWRT bug FS#181).
With mt7610 on an TP-Link RE200 v2 with OpenWRT TX power is too low (max 9dBm), cannot be changed above this and makes the 5Ghz radio unusable.

Searching here in the mt76 repository about similar TX power issues, I've found multiple similar reports:

TP-LINK RE200 problem with the operation of the WLAN chipset. OpenWRT rel 21.02rc4 #606
MT7610E: TX-Power Values incorrect -> low range #604
MT76x0: Correct VHT MCS 8/9 tx power eeprom offset #577
MT7615dn: 5G max power is 6dBm #574
Xiaomi r3p mt7615N low tx power 2ghz 5ghz #539
Low transmission power on MT7610EN #530
mt7603e max tx power is only 8 dBm on HiWiFi HC5962 #525
low tx power with mt76x0e driver #484
Low-incorrect txpower on Mediatek 7628 (TP-Link 840 ver 6.0) #279
Various issues with 5Ghz MT7610E #227
low tx power m7610e #216

And some other more.

While as in the TP-Link Archer C6 v3 (mt7613) where TX Power is stuck at maximum allows it to be perfectly usable, on other devices such as TP-Link RE200 v2 (mt7610) wifi is unusable due to the very weak 5Ghz signal power.

So instead of opening more bug reports here for my TX Power issues with mt7613 and mt7610, I've decided summarize the existing bug reports about TX power here so perhaps we can concentrate the developers' focus on this single bug report.

Devmax21 · 2021-12-06T12:50:13Z

I extracted stock firmware (Archer c2) and see that it doesn't use eeprom power values. It use values from file
SingleSKU_5G_FCC.txt
If we modify code to ability for load power values from file or hardcode they in variables then the issue will be fixed. But we need different values set for different routers.

sanitariu · 2021-12-06T13:33:15Z

I think these values are from db.txt file and we have it already so we can use that file instead wrong places in eeprom which sometimes leads to too much txpower or too little. Values from wireless-regdb - db.txt are exactly the correct values for all countries and domains.

dmsza · 2021-12-06T14:27:07Z

I'm not sure reg-db.txt should be used. I mean, while it correctly specifies the maximum power allowed for a given region, it might be greater than the radio supports.

I mean, let's say 30dBm is allowed for a given region/frequency. But the radio of a given device supports a maximum of 23dBm, for example.

This way, will setting the TX power for this radio to 30dBm damage it?

sanitariu · 2021-12-06T14:30:04Z

I think such devices would not be allowed the be imported in your country.

dmsza · 2021-12-06T16:13:59Z

That's not how things work in real life. Most manufacturers use a single hardware design for their devices which are sold globally. The TX power and other regulation constraints (such allowed frequencies and DFS channels) are limited by the firmware, not by the hardware. That's why there are "US" firmware, "EU" firmware and so on.

BTW, that's beyond the point of this bug report.

The issue reported here concerns MT76 driver and make it work according to the TX power which is allowed per region configured in OpenWRT.

Devmax21 · 2021-12-06T17:19:27Z

As I see, stock firmwares calculate power for 5G based on value MT_EE_5G_TARGET_POWER. And adjust tx power using SingleSKU_5G_FCC.
The MT76 calculate power for 5G using eeprom values (MT_EE_TX_POWER_DELTA_BW80 + offset) if tssi is disabled. And it use MT_EE_5G_TARGET_POWER if tssi is enabled.
I proposed to use MT_EE_5G_TARGET_POWER in #227 (comment) if tssi is disabled, but it is incorrect because power per rate doesn't corresponds to SingleSKU_5G_FCC. With that fix the real TX power is increased. I think that we should calculate correct power per rate and set proper value of delta in TX_ALC_CFG_1.

Devmax21 · 2021-12-06T19:30:47Z

I think these values are from db.txt file and we have it already so we can use that file instead wrong places in eeprom which sometimes leads to too much txpower or too little. Values from wireless-regdb - db.txt are exactly the correct values for all countries and domains.

I think these values is not from wireless-regdb. The wireless-regdb has only max power values for frequencies. But SingleSKU_5G_FCC has power table considering power per rate.

Devmax21 · 2021-12-07T07:21:58Z

This file from RE200. As you see, it has other values than Archer c2
SingleSKU_5G_FCC.txt

Neustradamus · 2021-12-09T00:44:35Z

To follow this ticket

ArtemiisFowl · 2021-12-09T11:13:22Z

If we modify code to ability for load power values from file or hardcode they in variables then the issue will be fixed. But we need different values set for different routers.

It is possible to specify own eeprom in openwrt for each device in dts file. see: #567

I also did some research about my tp link vr200v with mt7610e. power was low with default openwrt firmware. I managed to edit the right vals in eprom to use the correct txpower. Works good, but this is a hack and no fix since we cannot enable one power limit for all mt76 devices and patching dts file for every device is also not the right way.
Interesting is, that in stock router img theres a eprom file, but this also offers low tx power. I thought that perhaps this file is used with offset (antenna offset?) but i don't looked deeper in it.

Devmax21 · 2021-12-09T12:02:40Z

It is impossible for some devices. As I understand, dts info stored in uboot (correct me if I'm wrong). For example, we can't replace uboot for archer c2. It should be original for this device.

As I wrote, stock router doesn't use values from eeprom. It use values from the SingleSKU_5G_FCC file, placed in /etc/ and value MT_EE_5G_TARGET_POWER from eeprom as upper txpower limit.

nbd168 · 2021-12-09T12:11:29Z

SingleSKU does not override EEPROM, it only limits the txpower.

Devmax21 · 2021-12-09T13:02:53Z

SingleSKU does not override EEPROM, it only limits the txpower.

In mediatek driver for the txpower they use EEPROM_MT76x0_5G_TARGET_POWER for 5G

RT28xx_EEPROM_READ16(pAd, EEPROM_MT76x0_5G_TARGET_POWER, ee_val);
                        pAd->DefaultTargetPwr = ee_val & 0x00ff;

In the mt76 we get the txpower from eeprom MT_EE_TX_POWER_0_GRP4_TSSI_SLOPE when tssi is disabled -

        if (chan->band == NL80211_BAND_2GHZ) {
                addr = MT_EE_TX_POWER_DELTA_BW80 + offset;
        } else {
                switch (chan->hw_value) {
                case 42:
                        offset = 2;
                        break;
                case 58:
                        offset = 8;
                        break;
                case 106:
                        offset = 14;
                        break;
                case 122:
                        offset = 20;
                        break;
                case 155:
                        offset = 30;
                        break;
                default:
                        break;
                }
                addr = MT_EE_TX_POWER_0_GRP4_TSSI_SLOPE + 2 + offset;
        }

        data = mt76x02_eeprom_get(dev, addr);
        *tp = data >> (8 * idx);

In archer c2 eeprom offset MT_EE_TX_POWER_0_GRP4_TSSI_SLOPE = 0x76

000000000070:  FF FF FF FF│FF 00 00 FF│13 13 12 11│11 10 10 10
000000000080:  10 10 10 10│11 11 11 11│11 11 11 11│11 12 12 12
000000000090:  12 12 12 12│12 12 12 12│11 11 11 FF│FF FF FF FF

and value EEPROM_MT76x0_5G_TARGET_POWER = 0x1c

As you can see EEPROM_MT76x0_5G_TARGET_POWER is bigger then any values from MT_EE_TX_POWER_0_GRP4_TSSI_SLOPE. In result we have lower power with mt76.

Yes, SingleSKU does not override EEPROM and it is used for limits power per rate. As I understand, incorrect power per rate is not good and we need to use oem SingleSKU values for calculate correct power per rate. Is it right?

Devmax21 · 2021-12-09T16:13:29Z

Maybe I haven't been clear.

The mediatek driver set only one byte of TX_ALC_CFG_0 from MT_EE_TX_POWER_0_GRP4_TSSI_SLOPE in MT76x0_ChipSwitchChannel
(EEPROM_A_TX_PWR_OFFSET = MT_EE_TX_POWER_0_GRP4_TSSI_SLOPE + 2)

                /* 1. U-NII lower/middle band: 36, 38, 40; 44, 46, 48; 52, 54, 56; 60, 62, 64 (including central frequency in BW 40MHz)*/
                choffset = 14;
                ASSERT((pAd->TxPower[choffset].Channel == 36));
                for (i = 0; i < 6; i++)
                {
                        idx = i * 2;
                        RT28xx_EEPROM_READ16(pAd, EEPROM_A_TX_PWR_OFFSET + idx, Power.word);

                        if ((Power.field.Byte0 <= 0x3F) && (Power.field.Byte0 >= 0))
                                pAd->TxPower[idx + choffset + 0].Power = Power.field.Byte0;

                        if ((Power.field.Byte1 <= 0x3F) && (Power.field.Byte1 >= 0))
                                pAd->TxPower[idx + choffset + 1].Power = Power.field.Byte1;
                }
...

TxPwer = pAd->TxPower[Index].Power;

....

                RTMP_IO_READ32(pAd, TX_ALC_CFG_0, &Value);                                                                                                                                
                Value = Value & (~0x3F3F);                                                                                                                                                
                Value |= TxPwer;                                                                                                                                                          
                Value |= (0x2F2F << 16);                                                                                                                                                  
                RTMP_IO_WRITE32(pAd, TX_ALC_CFG_0, Value);

Higher byte set to 0. It is not clear for me. Why?

Or maybe I see wrong sources) I got it here https://github.com/zaccareal/openwrt-archer-c2/blob/master/package/mediatek/drivers/mt7610e/src/chips/mt76x0.c

yesrab · 2021-12-10T15:17:28Z

same issue for me too on my tplink archer c20 v4
5ghz network is not working ( it works once for a sec if I'm lucky)

any way I can fix this?

chinghanyu · 2021-12-11T03:04:52Z

@Devmax21 I am on the same boat and would like to thank you for sharing your findings. I have a TP-Link RE220v2 with OpenWrt 21.02.1 r16325 installed and my tests show OpenWRT's MTK driver sets TX power large enough for the U-NII-3 band channels (149-165); however, it sets extremely low TX power for U-NII-1 and U-NII-2A band ones. In just apart 5 meters away from each other and I can see the connection becomes unstable. I tried both channel 36 and 64, and they are barely usable.

Because at least the TX power for U-NII-3 band seems to be large enough, perhaps we can take a look on that part and decide how to fix the mid/lower band TX power.

dmsza · 2021-12-12T11:13:39Z

If I am reading correctly, most comments in this discussion are related to eeprom.c and the options to make it read the correct TX power limits for various mt76 devices.

While this is an actual defect and it must be fixed for multiple devices (as I mentioned I have this issue with a RE200 v2 device), I would like to bring the attention to the fact that there is other issue at play here.

For example, even if reading the TX power is fixed, it may not work since the code to set the TX power seems also not be working.

I did some thorough tests with the Archer C6 v3.2, the results are here: https://forum.openwrt.org/t/mediatek-mt76-ignoring-wi-fi-tx-power-configuration/106788

As you will be able to see, I was trying to reduce the TX power to troubleshoot some overlapping areas and to improve 802.11r. However changing the TX power has no effect at all.

So just fixing the TX power reading in eeprom.c might not fix this issue at all if the driver cannot configure the radio with intended TX power.

ptpt52 · 2021-12-13T22:27:56Z

mark.

Devmax21 · 2021-12-14T15:44:32Z

I got access to console via telnet on Archer c2 with stock firmware and see that power values looks almost the same as on mt76

Stock -

#define MT_TX_ALC_CFG_0                 0x13b0
#define MT_TX_PWR_CFG_0                 0x1314
#define MT_TX_PWR_CFG_1                 0x1318
#define MT_TX_PWR_CFG_2                 0x131c
#define MT_TX_PWR_CFG_3                 0x1320
#define MT_TX_PWR_CFG_4                 0x1324
#define MT_TX_PWR_CFG_8                 0x13d8


/var/tmp # iwpriv rai0 mac 13b0
rai0      mac:
[0x13b0]:2f2f0012  
/var/tmp # iwpriv rai0 mac 1314
rai0      mac:
[0x1314]:07070000  
/var/tmp # iwpriv rai0 mac 1318
rai0      mac:
[0x1318]:01010004  
/var/tmp # iwpriv rai0 mac 131c
rai0      mac:
[0x131c]:00000001  
/var/tmp # iwpriv rai0 mac 1320
rai0      mac:
[0x1320]:00000000  
/var/tmp # iwpriv rai0 mac 1324
rai0      mac:
[0x1324]:00000000
/var/tmp # iwpriv rai0 mac 13d8
rai0      mac:
[0x13d8]:3f3f0000

mt76 - use delta from EEPROM (-1)

MT_TX_ALC_CFG_0:2f2f1212
MT_TX_PWR_CFG_0:0x6063f3f
MT_TX_PWR_CFG_1:0x6063f03
MT_TX_PWR_CFG_2:0x3f3f3f03
MT_TX_PWR_CFG_3:0x3f3f3f3f
MT_TX_PWR_CFG_4:0x3f3f
MT_TX_PWR_CFG_8:0x3e3e003f

I tried to set the second byte for power in MT_TX_ALC_CFG to 0 and nothing changed.

As I understand power value in MT_TX_ALC_CFG changing power with step 1dB (I didn't find manual for mt7610 but I saw in manual for other similar mtk chip that step is 0.5 dB). But in the mt76 expected 0.5 dB.
I made patch that is work for me and tx power on router looks like good.

iw phy0 info

               Frequencies:
                        * 5180 MHz [36] (23.0 dBm)
                        * 5200 MHz [40] (23.0 dBm)
                        * 5220 MHz [44] (23.0 dBm)
                        * 5240 MHz [48] (23.0 dBm)
                        * 5260 MHz [52] (23.0 dBm) (radar detection)
                        * 5280 MHz [56] (23.0 dBm) (radar detection)
                        * 5300 MHz [60] (23.0 dBm) (radar detection)
                        * 5320 MHz [64] (23.0 dBm) (radar detection)
                        * 5500 MHz [100] (23.0 dBm) (radar detection)
                        * 5520 MHz [104] (23.0 dBm) (radar detection)
                        * 5540 MHz [108] (23.0 dBm) (radar detection)
                        * 5560 MHz [112] (23.0 dBm) (radar detection)
                        * 5580 MHz [116] (23.0 dBm) (radar detection)
                        * 5600 MHz [120] (23.0 dBm) (radar detection)
                        * 5620 MHz [124] (23.0 dBm) (radar detection)
                        * 5640 MHz [128] (23.0 dBm) (radar detection)
                        * 5660 MHz [132] (23.0 dBm) (radar detection)
                        * 5680 MHz [136] (23.0 dBm) (radar detection)
                        * 5700 MHz [140] (23.0 dBm) (radar detection)
                        * 5720 MHz [144] (23.0 dBm) (radar detection)
                        * 5745 MHz [149] (30.0 dBm)
                        * 5765 MHz [153] (30.0 dBm)
                        * 5785 MHz [157] (30.0 dBm)
                        * 5805 MHz [161] (30.0 dBm)
                        * 5825 MHz [165] (30.0 dBm)
                        * 5845 MHz [169] (disabled)
                        * 5865 MHz [173] (disabled)

This patch only for mt76x0. I think that the fix a similar for other chipsets, but I don't have other routers for testing.
Another issue - after calculated power limit, the power per rate has the same values.
with this patch will be decreased txpower and power per rate will be unchanged.

020-txpower-mt76x0.patch.txt

Devmax21 · 2021-12-14T15:56:57Z

I also did some research about my tp link vr200v with mt7610e. power was low with default openwrt firmware. I managed to edit the right vals in eprom to use the correct txpower. Works good, but this is a hack and no fix since we cannot enable one power limit for all mt76 devices and patching dts file for every device is also not the right way. Interesting is, that in stock router img theres a eprom file, but this also offers low tx power. I thought that perhaps this file is used with offset (antenna offset?) but i don't looked deeper in it.

I think the values in eeprom is correct. But we can increase the values and get tx power upper 23dB)

DragonBluep · 2021-12-14T17:35:52Z

MT7610E-EEPROMContentv06.pdf
Hope this document is helpful. I feel that only mt7610‘s transmit power is abnormal.

vbmithr · 2021-12-16T00:20:15Z

I also cannot detect 5Ghz antenna on my Totolink x5000r (MT7621/MT7915e), but it looks also like a power issue since everything else seems to be working. Using openwrt snapshot from ~1w ago.

alessandroflaminio · 2021-12-17T14:07:30Z

Experiencing the same issue on TP-Link RE200 v1 (MediaTek MT7610E) on OpenWrt 21.02.1 r16325-88151b8303. Tx-Power limited to 9 dBm on 5 GHz, BSSID undetectable from other devices.

thiagohd · 2021-12-29T12:11:37Z

Hello guys, I have also experienced the same problem with Wavlink AP, which has MediaTek MT7610E and MediaTek MT7688AN. Both 5Ghz and 2.4Ghz radios are with a similar issue.

workpush · 2022-01-03T21:16:21Z

Same issue also for me with a TP-Link TL-WR902AC v3, which is using a MT7610EN. Maximum Transmit power listed is 11dBm

Using OpenWrt 21.02.1 r16325-88151b8303

JsBergbau · 2022-01-07T00:06:29Z

This problem also affects WR902ac router. No matter what country is selected, maximum transmit power for 5 GHz radio is 12 dBm.

asiaon123 · 2022-01-07T02:06:25Z

One solution for my router(7603e) is to modify eeprom, making my 2.4g work fine at 30dBm.
but, I find out that the source code is not correspond to the document i found on the internet.

thiagohd · 2022-01-07T11:24:11Z

One solution for my router(7603e) is to modify eeprom, making my 2.4g work fine at 30dBm. but, I find out that the source code is not correspond to the document i found on the internet.

Hello @asiaon123, could you explain how you modified the eeprom in more details, maybe share the code? It would really help me and probably others, a lot. Thank you very much in advance!

hmh · 2023-10-20T11:06:19Z

(meh, no matter how much I edit it, it still feels like I am complaining it took too long to fix, which is not what I want to say. So, removed the comment).

Many thanks to everyone who worked on this! The next step is now to try to get backports wherever important, so that the fix will have as much impact as possible.

MoskiT87 · 2023-10-24T12:45:11Z

Thanks for pointing me in the right direction. I think the patch is wrong (see mailing list discussion), but here's my suggestion of how this could be fixed: https://nbd.name/p/74875b07

@nbd168 I've built and tested your patch. It works normally on extPA MT7610E. Thank you!

I immediately apologize for being off-topic, but can anyone tell me how an ordinary user like me can apply your patch?

cgm999 · 2023-10-25T11:21:37Z

@MoskiT87 I think for this particular issue you can use the binary patch way, works against the snapshots or releases .no need to worry with rebuilding.

cgm999 · 2023-11-20T12:57:30Z

@nbd168 Are you able to copy latest mt76 into openwrt main ?
Trying to understand why the issue reported in this bug is still present in latest openwrt commit

cheers

yesrab · 2023-12-07T08:27:21Z

hi anyone with tpLink Archer C20 V5 can you provide me with full flash dump

i have nuked my whole spi flash via the uboot console i need a full dump file to write to it again

enmaskarado · 2023-12-08T14:26:41Z

Looks like the patch is now in openwrt/main.

cgm999 · 2023-12-08T15:19:09Z

I am not seeing it based on commit desc

yesrab · 2023-12-08T15:21:28Z

hi anyone with tpLink Archer C20 V5 can you provide me with full flash dump

i have nuked my whole spi flash via the uboot console i need a full dump file to write to it again

can anyone?

yesrab · 2023-12-08T15:27:45Z

I am not seeing it based on commit desc

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8f782ed07dc23b64bb24f63ce31d939ee6afb5ad

probably here

cgm999 · 2023-12-08T15:55:05Z

@yesrab you are correct, I did not see it. finnally is in main !!!
on your flash wipe req, sorry .. I do not have that device ( and I have a few diff tplink models :)

MasterPIC · 2023-12-11T01:27:07Z

I just built updated source and no patch is required on TL-WR902AC v3.

cgm999 · 2023-12-21T15:33:17Z

I did several tests on re200 / re220 / wr902ac .. 5Ghz seems to be working ,maybe we can close this ticket :)

kvanbiesen · 2023-12-21T16:40:28Z

Weird, I never had issues on my Xiaomi 4a gigabit. (Mt7621 not affected?)

…

On Thu, Dec 21, 2023, 16:33 cgm999 ***@***.***> wrote: I did several tests on re200 / re220 / wr902ac .. 5Ghz seems to be working ,maybe we can close this ticket :) — Reply to this email directly, view it on GitHub <#633 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZ4APIVIJQVBRWQ5SV5JU3YKRJEZAVCNFSM5JMV22FKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBWGY2TAMBVGQZQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

smeathers · 2023-12-21T16:41:56Z

I did several tests on re200 / re220 / wr902ac .. 5Ghz seems to be working ,maybe we can close this ticket :)

Is this now in the latest build I can download without building it myself? Else can we leave this ticket open until that's the case?

cgm999 · 2023-12-22T07:15:59Z

Latest snapshot fixes the 5Ghz for 7610 . No ideea about others like 7612 etc

enmaskarado · 2023-12-25T01:27:54Z

The bug still affects TP-Link Archer C6 v3 (mt7603e + mt7613ben). TX power is stuck at maximum and cannot be decreased.

AbdulRahmannnnnn · 2023-12-25T04:21:41Z

I did several tests on re200 / re220 / wr902ac .. 5Ghz seems to be working ,maybe we can close this ticket :)

@cgm99 Why does the bug still occur on the latest firmware 23.05.2 (r23630-842932a63d) on TL-WR902AC v3? does replacing with 122c3cf2 still work to fix the bug?

MasterPIC · 2023-12-25T04:48:56Z

@AbdulRahmannnnnn r23630-842932a63d doesn't include the fix. You've to use a snapshot and install luci or download updated source and compile by yourself.
I'd expect a new release (23.05.3) for such a bug fix.

AbdulRahmannnnnn · 2023-12-26T00:50:38Z

@AbdulRahmannnnnn r23630-842932a63d doesn't include the fix. You've to use a snapshot and install luci or download updated source and compile by yourself. I'd expect a new release (23.05.3) for such a bug fix.

@MasterPIC I'm new to the world of networking and OpenWrt, sorry if my question is quite strange. Is there a firmware version of the TL-WR902AC that works fine without the need for binary patching or does this happen with all firmware versions? and can the 122c3cf2 value be applied to all versions?

cgm999 · 2023-12-26T14:30:12Z

@AbdulRahmannnnnn as @MasterPIC said,the current release 23.05.2 does not include the needed fix.
Options are :

use the latest snapshot untill there is a stable release that includes the fix,
binpatch 23.05.2 (my tests show that 122c3cf2 will work fine for wr902ac ) , you can create a simple .sh script that does it if .ko file changed..
recompile the whole image with the respective patch applied(for example if you are going to do that anyway because you want to change package list or maybe you want some kernel edit )

AbdulRahmannnnnn · 2023-12-27T16:38:01Z

@AbdulRahmannnnnn as @MasterPIC said,the current release 23.05.2 does not include the needed fix. Options are :

use the latest snapshot untill there is a stable release that includes the fix,

binpatch 23.05.2 (my tests show that 122c3cf2 will work fine for wr902ac ) , you can create a simple .sh script that does it if .ko file changed..

recompile the whole image with the respective patch applied(for example if you are going to do that anyway because you want to change package list or maybe you want some kernel edit )

Thank you @cgm999 @MasterPIC for your answer, I have copied and pasted the file into the appropriate directory according to your instructions cp /tmp/mt76x0-common.ko /lib/modules/$(uname -r)/mt76x0-common.ko , but why the directory /rom/lib/modules has not really changed, this can be seen from the description of the time it was last edited which is the same as the time this kernel was published(the time should be the same as the time when doing binary patching, right?). and the binary patching effect only applies until the router is turned off, when it is turned on again the bug appears as before. Is there an error in my process?

cgm999 · 2023-12-28T09:51:02Z

Binary patch the .ko file (is only for 7610 radio chip
hexdump -ve '1/4 "%.8x\n"' /rom//lib/modules/$(uname -r)/mt76x0-common.ko|sed -e 's/^122c54f2/122c3cf2/' |sed -re 's/(..)(..)(..(..)/\\\\x\4\\\\x\3\\\\x\2\\\\x\1/g'| xargs -n1 printf > /tmp/mt76x0-common.ko

Then verify is showing same size and diff md5
ls -ld /tmp/mt76x0-common.ko /lib/modules/$(uname -r)/mt76x0-common.ko
md5sum /tmp/mt76x0-common.ko /lib/modules/$(uname -r)/mt76x0-common.ko

If you see a diff md5 and same size.. copy the .ko to replace /rom
cp /tmp/mt76x0-common.ko /lib/modules/$(uname -r)/mt76x0-common.ko

Then reboot your device and hopefully 5Ghz will work.

MasterPIC · 2024-03-23T22:30:09Z

Release 23.05.3 available.
I just found patch is still required.

cgm999 · 2024-03-25T06:59:04Z

Yea, looks like the mt76 from openwrt-23.05 is only having a very little number of commits vs mt76 main. At least with binary patching is really easy to make it work if you do not want to recompile.

kvanbiesen · 2024-03-25T07:05:02Z

I have same issues with the latest snapshots and latest release on a Xiaomi gigabit first realese. Wifi randomly shuts down (no errors throw in log), it tries to enable itself and crashes again. Manuely disable wifi and enable it again also keeps saying no wifi active. It works fine on 23.05.0. on snapshots or 23.5.3 it's throws me errors. Did something change in the config file? Cause with factory image and default settings it seems to work. But hard to say as crashing usually appears after couple of days

…

On Mon, Mar 25, 2024, 07:59 cgm999 ***@***.***> wrote: Yea, looks like the mt76 from openwrt-23.05 is only having a very little number of commits vs mt76 main. At least with binary patching is really easy to make it work if you do not want to recompile. — Reply to this email directly, view it on GitHub <#633 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABZ4APOMPNXQQDGI56XOMJLYZ7DNFAVCNFSM5JMV22FKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBRG4ZTINJXHAZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

parthibx24 · 2024-04-18T15:19:22Z

Yea, looks like the mt76 from....

@cgm999 does the binpatch work for mt7612e? I am on latest openwrt build. Router is Netgear R6120.

cgm999 · 2024-04-18T16:11:51Z

@parthibx24 no.. is just for 7610E. Are you sure there are issues with your chip? In the latest snapshot (not in 23.05.XX) 7610E is fixed..

parthibx24 · 2024-04-19T04:00:56Z

@cgm999 yeah mine only shows 3dbm in the ui

nuclearcat · 2024-04-19T06:31:36Z

It might be EEPROM/calibration partition issue (not correct data in it)

cgm999 · 2024-04-19T07:37:31Z

I think the real question is if that txpower is really low.. did you tested from a station to see if is weak indeed?

dmsza changed the title ~~mt76 TX power not working in multiple chipsets (mt7610, mt7613, mt7615)~~ mt76 TX power not working in multiple chipsets (mt7610, mt7613, mt7615, mt7603) Dec 5, 2021

morrownr mentioned this issue Jan 5, 2022

(info) Very low TX power on Alfa AWUS036ACHM morrownr/USB-WiFi#34

Open

mt76 TX power not working in multiple chipsets (mt7610, mt7613, mt7615, mt7603) #633

mt76 TX power not working in multiple chipsets (mt7610, mt7613, mt7615, mt7603) #633

Comments

dmsza commented Dec 5, 2021 • edited

Devmax21 commented Dec 6, 2021

sanitariu commented Dec 6, 2021

dmsza commented Dec 6, 2021

sanitariu commented Dec 6, 2021

dmsza commented Dec 6, 2021 • edited

Devmax21 commented Dec 6, 2021 • edited

Devmax21 commented Dec 6, 2021 • edited

Devmax21 commented Dec 7, 2021

Neustradamus commented Dec 9, 2021

ArtemiisFowl commented Dec 9, 2021 • edited

Devmax21 commented Dec 9, 2021

nbd168 commented Dec 9, 2021

Devmax21 commented Dec 9, 2021 • edited

Devmax21 commented Dec 9, 2021

yesrab commented Dec 10, 2021

chinghanyu commented Dec 11, 2021

dmsza commented Dec 12, 2021 • edited

ptpt52 commented Dec 13, 2021

Devmax21 commented Dec 14, 2021 • edited

Devmax21 commented Dec 14, 2021 • edited

DragonBluep commented Dec 14, 2021

vbmithr commented Dec 16, 2021

alessandroflaminio commented Dec 17, 2021

thiagohd commented Dec 29, 2021

workpush commented Jan 3, 2022 • edited

JsBergbau commented Jan 7, 2022

asiaon123 commented Jan 7, 2022

thiagohd commented Jan 7, 2022

hmh commented Oct 20, 2023 • edited

MoskiT87 commented Oct 24, 2023

cgm999 commented Oct 25, 2023

cgm999 commented Nov 20, 2023

yesrab commented Dec 7, 2023

enmaskarado commented Dec 8, 2023

cgm999 commented Dec 8, 2023

yesrab commented Dec 8, 2023

yesrab commented Dec 8, 2023

cgm999 commented Dec 8, 2023

MasterPIC commented Dec 11, 2023

cgm999 commented Dec 21, 2023

kvanbiesen commented Dec 21, 2023 via email

smeathers commented Dec 21, 2023

cgm999 commented Dec 22, 2023

enmaskarado commented Dec 25, 2023

AbdulRahmannnnnn commented Dec 25, 2023 • edited

MasterPIC commented Dec 25, 2023

AbdulRahmannnnnn commented Dec 26, 2023

cgm999 commented Dec 26, 2023

AbdulRahmannnnnn commented Dec 27, 2023 • edited

cgm999 commented Dec 28, 2023 • edited

MasterPIC commented Mar 23, 2024 • edited

cgm999 commented Mar 25, 2024

kvanbiesen commented Mar 25, 2024 via email

parthibx24 commented Apr 18, 2024

cgm999 commented Apr 18, 2024

parthibx24 commented Apr 19, 2024

nuclearcat commented Apr 19, 2024

cgm999 commented Apr 19, 2024

dmsza commented Dec 5, 2021 •

edited

dmsza commented Dec 6, 2021 •

edited

Devmax21 commented Dec 6, 2021 •

edited

Devmax21 commented Dec 6, 2021 •

edited

ArtemiisFowl commented Dec 9, 2021 •

edited

Devmax21 commented Dec 9, 2021 •

edited

dmsza commented Dec 12, 2021 •

edited

Devmax21 commented Dec 14, 2021 •

edited

Devmax21 commented Dec 14, 2021 •

edited

workpush commented Jan 3, 2022 •

edited

hmh commented Oct 20, 2023 •

edited

AbdulRahmannnnnn commented Dec 25, 2023 •

edited

AbdulRahmannnnnn commented Dec 27, 2023 •

edited

cgm999 commented Dec 28, 2023 •

edited

MasterPIC commented Mar 23, 2024 •

edited