Open dmsza opened 2 years ago
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.
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'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?
I think such devices would not be allowed the be imported in your country.
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.
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 https://github.com/openwrt/mt76/issues/227#issuecomment-985809672 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.
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.
This file from RE200. As you see, it has other values than Archer c2 SingleSKU_5G_FCC.txt
To follow this ticket
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: https://github.com/openwrt/mt76/pull/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.
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.
SingleSKU does not override EEPROM, it only limits the txpower.
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?
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
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?
@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.
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.
mark.
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.
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)
MT7610E-EEPROMContentv06.pdf Hope this document is helpful. I feel that only mt7610‘s transmit power is abnormal.
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.
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.
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.
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
This problem also affects WR902ac router. No matter what country is selected, maximum transmit power for 5 GHz radio is 12 dBm.
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.
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!
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!
I explained it here and in following comments. But it's not a fix, it's a dirty hack https://github.com/openwrt/mt76/issues/227#issuecomment-944611998
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.
The source code is right. Мaximum transmit power for 5 GHz radio is only chip power. We don't know external power for different routers. In this case code get max power from eeprom. And we use max power for router. As example on tp-link c2 we have antenna with 5dBi. Max power rate is 6. And chip max TX power is 12. As result we have effective max TX power is 12+5+6=23 dBm.
We can hardcode max power in source code, but we will not know what effective TX power is used.
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!
Yeah, for my case, according to the source code of 7603:
mt7603/init.c
if (ext_pa && is_mt7603(dev))
target_power = eeprom[MT_EE_TX_POWER_TSSI_OFF] & ~BIT(7);
and
mt7603/eeprom.h
MT_EE_TX_POWER_TSSI_OFF = 0x0f2,
I checked my eeprom that my 0x0f2
is 00, that cause my target_power stay at 6dBm. And i changed it to 2D
which works fine now.
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.
The source code is right. Мaximum transmit power for 5 GHz radio is only chip power. We don't know external power for different routers. In this case code get max power from eeprom. And we use max power for router. As example on tp-link c2 we have antenna with 5dBi. Max power rate is 6. And chip max TX power is 12. As result we have effective max TX power is 12+5+6=23 dBm.
Absolutely, it's true that we should get the target power according to the eeprom. What i am confusing is i can't find the documentation for MT_EE_TX_POWER_TSSI_OFF = 0x0f2
, which makes my router works fine.
Guideline of 7603: MT7603E-EEPROM_Content_v1_0_guideline.zip
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!
Yeah, for my case, according to the source code of 7603:
mt7603/init.c
if (ext_pa && is_mt7603(dev)) target_power = eeprom[MT_EE_TX_POWER_TSSI_OFF] & ~BIT(7);
and
mt7603/eeprom.h
MT_EE_TX_POWER_TSSI_OFF = 0x0f2,
I checked my eeprom that my
0x0f2
is 00, that cause my target_power stay at 6dBm. And i changed it to2D
which works fine now.
@asiaon123 Thank you very much! I will test it with my colleagues. Could you also explain how did you check the content of your EEPROM?
I would like also to debug some of this code, is there an efficient way to do this even if it is by using print functions to the kernel? Does it work only by calling printf?
Also, when we run the command below we get all zero values, is it right??
I'm going to add myself to the list of those also affected. Alfa AWUS036ACHM, just purchased. I do not have this issue with my other MediaTek chipset based adapters (MT7612U) or my Alfa AWUS036NH (Ralink 3070). Following this thread closely, thanks all for your efforts.
Hello guys, the EEPROM content for WAVLINK WL-WN570HA1 (AERIAL HD2 – AC600), which has MediaTek MT7610E and MediaTek MT7688AN, according to the command hexdump /sys/kernel/debug/ieee80211/phy0/mt76/eeprom
is:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 76 28 02 02 3F 80 FA 5D B2 8A 00 00 00 00 00 00 v(..?€ú]²Š......
00000010 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000020 00 00 00 00 00 20 00 00 3F 80 FA 5D B0 8A 3F 80 ..... ..?€ú]°Š?€
00000030 FA 5D B1 8A 36 11 00 0E FF FF 01 00 00 00 00 00 ú]±Š6...ÿÿ......
00000040 00 00 00 11 00 00 00 00 00 30 00 00 00 00 00 00 .........0......
00000050 00 82 94 00 BB 40 CA C0 92 2A 93 93 CA 40 00 02 .‚”.»@ÊÀ’*““Ê@..
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000A0 C6 C6 C4 C4 C0 C4 C4 C0 C4 C4 C4 C4 C0 C0 00 00 ÆÆÄÄÀÄÄÀÄÄÄÄÀÀ..
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0 03 11 14 10 10 14 00 00 1A 00 2A 22 35 31 35 01 ..........*"515.
000000D0 40 39 4D 46 7F 7F 00 7F 00 00 00 00 00 00 00 00 @9MF............
000000E0 1D 11 1D 11 35 1C 35 1C 35 1E 35 1E 19 17 19 17 ....5.5.5.5.....
000000F0 00 02 00 00 80 96 88 80 00 0A 00 00 00 00 00 00 ....€–ˆ€........
00000100 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 77 ...............w
00000130 1D 11 1D 11 7F 15 7F 15 7F 17 7F 17 3B 10 3B 10 ............;.;.
00000140 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
According to the MT7628/7688 EEPROM Content Programming guide v2.0, there is no reference to MT_EE_TX_POWER_TSSI_OFF=0xF2
as already mentioned. Somehow, it is used in this lines of code at mt7603/init.c > mt7603_init_txpower()
, however, I believe that it only applies to devices which have 0x7603 as chip id in the EEPROM, which is not my case:
if (ext_pa && is_mt7603(dev))
target_power = eeprom[MT_EE_TX_POWER_TSSI_OFF] & ~BIT(7);
I actually don't understand the line above. But according to the guideline, for PA TSSI Offset, we should use TX0_PA_TSSI_LSB and TX0_PA_TSSI_MSB: (0x56 [bits 7:4]) OR (0x57 [bits 7:0] << 3)
. As for PA TSSI Slop should be used TX0_PA_TSSI_LSB: 0x56 [bits 3:0]
.
In the same function, the target_power
gets the right offset from the EEPROM since it uses MT_EE_TX_POWER_0_START_2G + 2
, which results in 0x56+2 = 0x58
, and according to the guideline is exactly the Tx0 Target Power registry. So I believe this part is right. But I don't understand the & ~BIT(7)
part, which does not make sense to me and there's no evidence in the guideline. Maybe there's something to to with the limits of the values for power... idk.
For phy1, according to command line hexdump /sys/kernel/debug/ieee80211/phy1/mt76/eeprom
the content of the EEPROM is:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 76 10 01 00 3F 80 FA 5D B3 8A 76 10 14 C3 00 00 v...?€ú]³Šv..Ã..
00000010 00 00 76 10 14 C3 00 00 00 00 0C 00 46 43 01 00 ..v..Ã......FC..
00000020 FF FF 9F FF FF EF 3E 30 9B 3C FF FF FF FF FF FF ÿÿŸÿÿï>0›<ÿÿÿÿÿÿ
00000030 FF FF FF FF FD 11 10 08 FF FF 01 44 FF FF 99 99 ÿÿÿÿý...ÿÿ.Dÿÿ™™
00000040 88 8C 07 FF 0C 00 00 00 0B 00 00 00 0A 00 FF FF ˆŒ.ÿ..........ÿÿ
00000050 80 FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 €ÿ..............
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF ..............ÿÿ
00000070 FF FF FF FF FF FF FF FF 1D 1D 1C 1C 1B 1C 1B 1B ÿÿÿÿÿÿÿÿ........
00000080 1A 1A 19 19 17 17 17 17 17 17 17 17 17 17 17 17 ................
00000090 17 17 17 17 19 19 1A 19 1A 1A FF 1A FF FF FF FF ..........ÿ.ÿÿÿÿ
000000A0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
000000B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000000D0 FF FF 81 1A 74 40 00 95 00 00 00 00 9B 64 00 00 ÿÿ..t@.•....›d..
000000E0 3D 3D 3C 00 3D 3D 3C 00 3D 3D 3C 00 3D 3D 3C 00 ==<.==<.==<.==<.
000000F0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000120 07 07 00 04 07 07 00 04 06 06 00 04 FF 3F FF FF ............ÿ?ÿÿ
00000130 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
I found some reference to 0xF2, but I don't know if it has to do with the EEPROM. Topics 2.9.1 and 2.9.1.6 (I'm not sure I actually can attach this files in here, if not, please remove it): MT762876037636 ATE User Manual.pdf
@Devmax21 In one of your comments above you reference a patch you created, 020-txpower-mt76x0.patch.txt. Can you go into more detail how a noob to OpenWrt & Linux might go about applying said patch? I have an Alfa MT7610U I could really use it on.
I'm going to add myself to the list of those also affected. Alfa AWUS036ACHM, just purchased. I do not have this issue with my other MediaTek chipset based adapters (MT7612U) or my Alfa AWUS036NH (Ralink 3070). Following this thread closely, thanks all for your efforts.
its good that you have no issues, while I'm having issues with my TP-Link Archer c20 V4 with 5G network, after watching this thread i just had to bail on my archer c20 and i bought a TP-LInk Archer A7 V5 since it doesn't have any mtk chips. i will be still watching this thread since i still have my archer c20 which I'm now just using as a switch.
@asiaon123 how did you check that your target_power was 6dBm?
For me, I changed directly in code so target_power = 60 (30 dBm) at mt7603/init.c > mt7603_init_txpower()
and mt7603/mcu.c > mt7603_mcu_set_channel()
, however I had no success in changing the actual power emitted by the router. It's like the changes had no effect in the chip functioning.
Also, EEPROM hexdump doesn't change its values.
@yesrab Oh, yes I'm taking issue with my brand new, somewhat pricey USB adapter only outputting 2mW when it's supposed to be one of the best adapters out there for linux. I bought this thing on several recommendations and here it sits, useless in OpenWrt (Alfa AWUS036ACHM).
...after watching this thread i just had to bail on my archer c20 and i bought a TP-LInk Archer A7 V5 since it doesn't have any mtk chips
It's a shame, I'm reaching that point too. After seeing this has been ongoing for 3+ years I see no hope in it actually being fixed. Essentially, my brand new top of the line adapter is bricked right out of the box. Does not bode well for MediaTek chipsets given all the products & users impacted by this issue. This isn't just one chipset affected... it's a problem.
IMO MediaTek should be responsible for resolving this issue. Whether it be assisting developers to correct it or doing it entirely in-house, I don't care. Their network adapters/chipsets not working in OpenWrt doesn't make sense to me. Like, it's one of the most popular linux networking OSs out there. We're not asking for it to do anything more than what's advertised on the box but it fails to meet even the most basic functionality.
Following this, I have a small fleet of MT7612e/7603e with a 7621 SoC with super low power.
Would appreciate even a hack to the .DTS or patches at this point (must work in 19.07.x )
Hello again guys, my team and I tried to change the target power value inside the functions, but it didn't change anything. We also checked and changed the offset values cited in this issue, but we haven't had success.
Looking at the EEPROM content, nothing changed in it, which is really weird I guess.
Obter o Outlook para Androidhttps://aka.ms/AAb9ysg
From: JFtico @.> Sent: Tuesday, January 18, 2022 7:00:10 PM To: openwrt/mt76 @.> Cc: Thiago Henrique Deicke @.>; Comment @.> Subject: Re: [openwrt/mt76] mt76 TX power not working in multiple chipsets (mt7610, mt7613, mt7615, mt7603) (Issue #633)
Following this, I have a small fleet of MT7612e/7603e with a 7621 SoC with super low power.
Would appreciate even a hack to the .DTS or patches at this point (must work in 19.07.x )
— Reply to this email directly, view it on GitHubhttps://github.com/openwrt/mt76/issues/633#issuecomment-1015872596, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABXFYXEWW6MT7XQEUOQMMKTUWXPGVANCNFSM5JMV22FA. Triage notifications on the go with GitHub Mobile for iOShttps://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Androidhttps://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you commented.Message ID: @.***>
@thiagohd Thanks much for all your efforts regarding this. What do you think are next steps?
@thiagohd Thanks much for all your efforts regarding this. What do you think are next steps?
I don't know. My team and I are really new into OpenWRT, and we don't understand the underlying routines nor the way these microprocessors are configured. We entered in the OpenWRT world because of all the benefits it has, like mesh network and a lot of other capabilities. It is the best router OS so far.
We tried some more tests using the OEM firmware. On the WAVLINK OEM firmware, we can connect to the router via telnet and copy partitions through tftpd. We managed to copy the Factory partition (EEPROM) from the OEM Firmware.
We tried changing the target power in the OEM firmware (through its web interface - which has 3 power levels - low, medium and high). The power really changed, we could prove that it changed through RSSI tests. After changing the target power, we copied the Factory partition and checked if the values inside it have changed from one power configuration to another. It did not change. So I guess the values in the EEPROM are not changed at all during configuration in the OEM firmware.
We entered in the OpenWRT world because of all the benefits it has, like mesh network and a lot of other capabilities. It is the best router OS so far.
Agreed. I'm a user and not a developer, please forgive my ignorance when asking questions regarding some matters.
Also, please forgive me for asking but when you say you have a team or "we", what are you referring to? I think it's exceptional to have these resources to help resolve this issue. All this is very new to me. Your description of your troubleshooting was easy to follow, thank you.
Past the nitty gritty coding that I don't fully understand, what kind of engagement do we have with MediaTek themselves in regards to this issue? Has anybody/can anybody reach out to someone either in a support role or an engineering role in order to bridge our gap in knowledge regarding these settings? I'm having the exact same issue with both Raspbian and OpenWrt (MT7610U) so it's not OS specific. I just don't know if we're going to come to a solution without engagement from MediaTek so people like you and your team can do what you do best.
Well, was it something I said..?
I spoke to Alfa support and they said it's a known bug that inaccurately reports the tx power and that they would follow up when a new driver is available for the AWUS036ACHM. Oh well, that'll be... never.
It's less of a hassle for me to return the adapter and convert to an RTL8812AU chipset that (shockingly) seems to have accurate power adjustments. But I kind of want stick it out, too, I like the manufacturer and the chipset otherwise.
I am provide some info in https://github.com/openwrt/mt76/issues/227, hope it help to debug eeprom loading/parsing.
iv'e read all of the fixes, only one does help, its not a nice solution, but it works so that i can use 5ghz network on my RE200v2 eeprom.patch.gz it goes gunzipped to openwrt/package/kernel/mt76/patches or openwrt-snapshot-r19472-de7535a6ac-ramips-mt76x8-tplink_re200-v2-squashfs-sysupgrade.bin.gz
for the one who doesn't want to build
after the HACK im able to set 20dbi on 5ghz an get +20dbm on a 20m mesh-route, compared to my fritzbox its like 17dbi Only Channels below 100 does work
Just reading eeprom.c:
In method mt76x0_get_delta shouldn't we use "MT_EE_TX_POWER_DELTA_BW80" instead of "MT_EE_5G_TARGET_POWER" ?
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:
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.