TP-Link Archer MR600 exploration

[BulldozerBSG]

@shankarinece

Included a bin shared by @nerijus here to fix 5GHz WiFi instabilities.

Analysis of the boot logs, flash data of factory firmware showed that (EU, HW 2.0):

1. uboot env -

bootargs=console=ttyS1,115200
  root=/dev/mtdblock2
  rootfstype=squashfs
  init=/sbin/init printk.time=1
  flash_size=0x1000000
  part_num=6
  partitions=
    0000000000020000uboot,
    0002000000200000os-image,
    0022000000da0000file-system,
    00fc000000010000rom-config,
    00fd000000010000user-config,
    00ff000000010000radio, <--------------------------- THIS

0x00ff0000 - radio partition offset
0x00010000 - radio partiton size

2. kernel boot log - mtd:

[    2.008000] mtd .name = raspi, .size = 0x01000000 (16M) .erasesize = 0x00010000 (64K) .numeraseregions = 0
[    2.020000] Creating 8 MTD partitions on "raspi":
[    2.024000] 0x000000000000-0x000000020000 : "boot"
[    2.028000] 0x000000020000-0x000000220000 : "kernel"
[    2.036000] 0x000000220000-0x000000fa0000 : "rootfs"
[    2.040000] mtd: partition "rootfs" set to be root filesystem
[    2.048000] 0x000000fa0000-0x000000fb0000 : "dualconfig"
[    2.052000] 0x000000fb0000-0x000000fc0000 : "ispconfig"
[    2.060000] 0x000000fc0000-0x000000fd0000 : "romfile"
[    2.064000] 0x000000fd0000-0x000000fe0000 : "config"
[    2.068000] 0x000000fe0000-0x000000ff0000 : "radio" <- This is different from uboot

3. kernel boot log - wifi drivers

[   17.052000] MT7603E-->NVM is FLASH mode, flash_offset = 0xff0000
[   17.060000] MT7603E-->1. Phy Mode = 14
[   17.064000] MT7603E--> ####  read 2.4G cal from flash !! ####
[   17.096000] spiflash_ioctl_read, Read from 0x00ff0000 length 0x10000, ret 0, retlen 0x10000
[   17.108000] read radio success, offset 0xff0000, size 0x200
[   17.112000] MT7603E-->@@@  NICReadEEPROMParameters : pAd->FWLoad=0 

[   35.580000] NVM is FLASH mode. dev_idx [1] FLASH OFFSET [0xFF8000]
[   35.584000] 
[   35.584000] ####  read 5G cal from flash !! ####
[   35.620000] spiflash_ioctl_read, Read from 0x00ff0000 length 0x10000, ret 0, retlen 0x10000
[   35.632000] validFlashEepromID(): eeFlashId=7663, pAd->ChipID=7663

EEPROM params for WIFI is loaded (by function spiflash_ioctl_read) from offset 0xff0000 bypassing mtd sections

4. mtd part - radio
   The partition is empty. Nothing but FFFFF...

5. uboot - read flash from 0xff0000

# spi read 0xff0000 0x10000
read len: 65536
3 76 b 0 0 c 43 26 60 78 3 76 c3 14 ff ff ff ff 3 76 c3 14 ...

This is very reminiscent of a real "radio" partition.

---

This is a patch that makes corrections to mtd partitions

$ git diff
diff --git a/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts b/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
index 165b48d209..6fa35d5a6d 100644
--- a/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
+++ b/target/linux/ramips/dts/mt7621_tplink_mr600-v2-eu.dts
@@ -137,8 +137,13 @@
                        };
 
                        partition@fe0000 {
-                               label = "radio";
+                               label = "fakeradio";
                                reg = <0xfe0000 0x10000>;
+                       };
+
+                       partition@ff0000 {
+                               label = "radio";
+                               reg = <0xff0000 0x10000>;
                                read-only;
 
                                nvmem-layout {

After this patch there is no need to flash third-party eeprom to fix WIFI

---

Is there anyone willing to confirm the information collected?

[stefandoesinger]

Yes, I can confirm @BulldozerBSG's findings re the wifi radio partition. I took a backup of the original (wrong) radio before writing the one from this forum but never looked at it. I now checked, and it was full of 0xff.

With your patch to the DTB fixing the radio partition offset 5ghz wifi works fine. In my early testing I don't see any performance difference between the firmware from this thread and the proper one from the router.

I don't have any old numbers from the 2.4 ghz wifi to compare to. I'll revert the patch when I have time to check.

I get a net transfer rate of about ~680-700 mbit/sec on 5ghz and 80mbit/sec on 2.4 between my M2 macbook and the router. With the stock firmware I got 650 and 50 respectively, but take this with a grain of salt. I noticed after flashing the router with openwrt that the speed is sensitive to how the laptop is positioned, the position of my office door or if the wifi antennas of the router moved.

[gzahl]

@BulldozerBSG I am happy to test, if you have some instructions. I have been running OpenWRT on this router 1 or 2 years ago. But it somehow forgot its configuration after a couple of reboots, which was a big problem for me, so i reverted back to the original firmware. I don’t know if that is still a problem, but i want to give it a second try. Original firmware is very limited. Works fine as basic LTE Router, which was most important for us, but does not even allow Wifi Repeater mode..

edit: Oh well, just realized i don’t have any device with LAN port or network cable available right now. So i can’t flash anything before next week.

Can you give a pointer how to apply your patch to the bin file? How is it unpacked/repacked after applying the patch?

[stefandoesinger]

This is a patch to the openwrt source code. You’ll have to compile openwrt yourself to make use of it: openwrt.org/docs/guide-developer/toolchain/use-buildsystem

[Iggy87100]

is there an image with the patch somewhere? I don’t mind flashing and testing, building it myself will take me a while though

[stefandoesinger]

I’ve uploaded the build I am currently running to https://drive.google.com/drive/folders/1eQDGzEu7jdpxbInuk0V4QPFRa-fYEkrq .Use it at your own risk. It should have ssh on port 22 and LUCI on ports 80 and 443 running, but you might have to recover via U-Boot/tftp.

I recommend to back up your configuration, flash my image with sysupgrade -n (to wipe away your configuration), test it, then go back to your previous image with sysupgrade -n and restore your backup.

If @BulldozerBSG’s theory applies to your device too, 5 ghz wifi should just work, without flashing anything to the radio partition.

I put the .config file I used in the Google folder. This build is built from commit b2116dbce4976ee9596d90964a4f145440b1c51e, with 926314ab (Energy Efficient Ethernet disable)
reverted and the patch by @BulldozerBSG applied.

[Iggy87100]

i can flash it while keeping my settings too and it works. (tested that way out of curiosity).
it works better than the normal image, speed seems faster, also proper values appear in the power options for the 5 GHz radio. however there’s still the option for 160 MHz channels that is not working: when selected radio appears to be on, but is not. 12, 40 and 80 seem to be fine.

[stefandoesinger]

So the Wifi works for you as-is with the image? If you previously uploaded the calibration data from this thread you can compare the two mtd partitions (fakeradio and radio) and see if they are different. If you don’t see a fakeradio partition in /proc/mtd then you somehow don’t have my kernel build.

Re the faster speed, if you see this in the web interface, this is primarily because I am using OpenSSL instead of mbedtls. It has some pitfalls though, see Debugging memory use / OOM crashes for what I am facing.

I haven’t looked at the wifi power options with the original radio yet. I see 23 dbm for 5 ghz wifi, and I think that was the same with the radio image from this forum. 2.4 ghz goes up to 19 dbm, and I believe it was 20 before. That might explain why the 2.4 ghz wifi works better.

I built the kernel with a hack to enable DFS channels I described in this thread earlier, but I am not actually using that - I am running the 5 ghz wifi on channel 36.

[Iggy87100]

to compare the speed i just push large files within the lan, don’t have the number now in my head, but i see it’s a bt faster, but otoh not so much that it would bother me i use channel 153 for this. and the “normal” image has broken power settings. for 5 GHz i see this:

driver default
0 dBm (1 mW)
1 dBm (1 mW)
2 dBm (1 mW)
3 dBm (1 mW)

leaving it on driver default i have this

Channel: 153 (5.765 GHz)
Tx-Power: 3 dBm

with your’s i get:
driver default
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)
21 dBm (125 mW)
22 dBm (158 mW)
23 dBm (199 mW)

driver default goes with 23 dBm, and this is noticeable on scanners and in the next room as my walls are eating WiFi like kids candy.

MD5 (i know, i know, but for that it’s good enough i think)

ecb99e6ffea7be1e5419350f725da86b *normal.mtd7.radio.bin
ecb99e6ffea7be1e5419350f725da86b *patched.mtd7.fakeradio.bin
fed781df5c433b596bf6507104a73fcb *patched.mtd8.radio.bin

normal: OpenWrt 24.10.0, r28427-6df0e3d02a
patched: OpenWrt 24.10-SNAPSHOT, r28785+2-b2116dbce4

as for now i’m just flashing one over another, seems to work

[stefandoesinger]

I checked my md5sums:

ecb99e6ffea7be1e5419350f725da86b mr600-radio-backup
fe9ea3976c42e976138891546da900e9 fakeradio
96cc9375be69698edde57b624dd5ccbd radio

The backup file is what I backed up before flashing the binary from earlier in this thread. It’s the empty (0xff) radio partition. Since you have the same still in use it makes sense that you get nonsense power values from the driver. Flashing the blob from this thread fixed that for me, so I didn’t see a difference with the patched build.

The fakeradio file is (de facto) the binary from this thread, but I read it back on the device.

The “radio” file is my device’s actual calibration data.

sha256sum for the sake of it:

71189f7fb6aed638640078fba3a35fda6c39c8962e74dcc75935aac948da9063 mr600-radio-backup
c537824426d695edbb9fda2f0a05990d34eb29c56d7b7bb9f1c0a6893ca6e73a fakeradio
29c6e0fad30cf9f5b245044ec5a3edec36041df81965b820081f5ac1556035e9 radio

(I got “shasum” in my muscle memory due to MacOS, and my openwrt only has sha256sum, so that’s my go-to hash tool)

[Iggy87100]

ok, so i went back, installed the blob that i must have forgotten in the past. now with normal and your build i have the same options, speed seems now the same too, may be the fact that the signal got better.
but the important part: DFS works with your version, does not on normal. tested on 108, 112 116 120 - all DFS channels, 149+ works regardless, but for 100-144 your changes are needed

[stefandoesinger]

I think the important thing is that @BulldozerBSG‘s patch will make 5g WiFi work out of the box, without flashing any magic blobs. @BulldozerBSG, if you send a pull request please make a note here and I’ll add a comment to the PR that I tested your patch.

The DFS channel are a different hack in my build though, see my comment in this thread from May 22: TP-Link Archer MR600 exploration - #170 by stefandoesinger . They are disabled in the stock firmware too. It is likely that the hardware is not capable of detecting radar pulses, either at all or while sending. As such, operating a WiFi in a DFS channel with my hack may violate regulations and get you in trouble. I just carry that hack in my build for short term testing.

If you live in an area with known weather radar activity and have a second router with known good DFS support, you could try to run both on the same channel and see if the MR600 vacates the channel whenever the known good router does. We can’t prove that DFS works properly that way, but we can prove the opposite: If the mr600 does not vacate the DFS channel, we can send a patch to the Kernel replacing the “DFS has not been tested” comment with “DFS has been tested and found not to work”. Just make sure to shut down the mr600 ASAP when the working router changes channels. And maybe retain a lawyer.

I used to live in Vienna for a long time, and DFS channels were pretty much unusable - my router (an entirely different device) used to get knocked away from channel 132 within minutes.

[Iggy87100]

i may be too far from anything that would cause the router to hop. i will try to test, but even the neighbour routers don’t seem to hop around. from the DFS channels.

Update: nothing i have around causes the router to change the channel. tested on 108, as this is one of the channels i can put other routers on too, but this is not enough to make it bounce. possibly the router recognises it’s a wifi signal and ignores it.

tried to it the channel with a harmonic frequency from a walkie-talkie, but also no luck, most likely the 8th harmonic is too challenging, even for the cheap crappy Chinese radios

would routers with a working DFC recognition not throw out something in one of the logs? maybe easier to check that way if something is ever detected

[stefandoesinger]

From reading some of the pull requests for DFS support for this device I noticed that I missed a change in my hack. It enables and uses the DFS channels but if the firmware reports radar signals the driver ignoes it. I’ll try to update my build later today.

That said, other WiFi devices shouldn’t cause a DFS channel change. WiFi devices should be able to tell the difference between Radar and other WiFi devices. I am not an expert on this though, so no idea if you can achieve anything with the Walkie-Talkie. My uneducated guess is that if it has a sound input to connect external microphones and can transmit on or near any of the DFS frequencies, you might be able to persuade some software defined radio software to output something on your soundcard to feed into the Walkie-Talkie. But you sound like you have more knowledge in this area than I do.

It would be fun to try to build a WiFi device out of a cheap walkie-talkie + a sound card

[Iggy87100]

that would not work as such different types of modulation etc. and using the soundcard like in the AX.25 days it would be slow , like really 1980s slow

i was thinking that the router would recognise and ignore wifi signals, but a burst from a radio will be noting like a wifi signal, so it may work. i found something in my collection that is generating a very weak signal, but i can measure it, so it is there. i will figure out a way to feed it straight into the router, so that it will be strong enough to be detected and then I'm curious if it will detect anything.

plan B is simpler: to take the router somewhere closer to a radar, but at the moment i would not know where

fresh tomato on another router that is on the same channel seems to behave the same so far, there’s a vanilla sagem around here too, but i’m wait for access

[stefandoesinger]

I have uploaded some new files.

I HAVE NOT TESTED THEM MYSELF YET. THE IMAGES MIGHT NOT BOOT.

I think I fixed the DFS hack by including an extra change in mt7615/mac.c that actually enables radar watching. The chatter in the MRs suggests that it might cause the router to detect radar pulses when none exist and needlessly switch away from DFS channels. It might also not detect actual radar pulses and get you in legal trouble.

mr600-customized.sysupgrade.bin is the build with my .config. LuCI, https-dns-proxy, statistics, openwrt-full, wpad-full, openssl, nftables-qos, nftables bandwidth monitor, luci-sms-tool-js, no ipkg/opkg status, so you can’t install additional packages. I add and remove things by rebuilding my image.

mr600-defconfig-luci.sysupgrade.bin uses the default openwrt build settings, but with the same code modifications as the other build. So in theory you should be able to install external packages. LuCI is enabled so that users who are not familiar with the Linux command line have a chance to flash an official OpenWRT only build via the browser. If you run OpenWRT with the shell only I expect you to be able to make your own builds .

Again I haven’t tested it because I don’t want to reboot my router at the moment. I am trying to collect memory use statistics over a few days.

The patches I applied to the code are in subdirectory patches. There’s a readme file with basic descriptions. They consist of:

1. Revert the EEE disable. See the linked forum thread. If you have EEE-capable devices, especially 10mbit/100mbit ones, please provide feedback in the linked thread.
2. The radio partition offset fix by @BulldozerBSG
3. Hacks to enable DFS
4. A partial revert of an upstream commit. The goal of the revert is to reduce memory consumption. See Debugging memory use / OOM crashes . If you are switching between the official openwrt build and mine I’d be interested in data about memory use, especially during high bandwidth use. Post findings in the linked thread.
5. (Edit): The openwrt base is commit b2116dbce4976ee9596d90964a4f145440b1c51e
   from the openwrt-24.10 branch.

AGAIN, I DID NOT TRY TO BOOT EITHER IMAGE. YOU MIGHT HAVE TO RECOVER YOUR DEVICE WITH A SERIAL CABLE.

[Iggy87100]

@stefandoesinger

mr600-defconfig-luci.sysupgrade.bin is working i let it run now and see if it catches something.
it behaves already a bit different: starts the radio after a scan, that takes 60 seconds. but so far no radar detected

[stefandoesinger]

After collecting 3 days of memory use I flashed the build myself (the mr600-customized one) and set it to channel 64.

[stefandoesinger]

I have created a pull request for the radio partition fix, crediting @BulldozerBSG in the commit message for finding the issue: https://github.com/openwrt/openwrt/pull/19790

I’ve also sent a pull request for for 24.10 stable branch fixing (or at least improving) the OOM errors. This got merged already, commit 92d4f597. If you router crashes every now and then and you built openwrt yourself from the openwrt-24.10 branch, I recommend to update. The stable branch was never affected by the problem.

[stefandoesinger]

Is there anyone in this thread who had 5ghz WiFi working well out of the box, i.e. without flashing the radio blob? A concern that came up on my pull request is that some devices might have the radio eeprom at 0xfe0000 - changing the location where openwrt expects the data would negatively impact them.

I realize someone with a nicely working router is less likely to monitor a thread like this, but asking is worth a try .