OpenWrt support for TP-Link Deco M4R

Looking like good progress over at m5 thread

1 Like

Hey @alex3305 have you solve the max speed issue? I have a 500mbps connection and I don't want it to be capped on the 5 GHz network, have you successfully tryed the overclock of the CPU?

I'm going to ask here,
I tried on other places, but haven't found a real solution yet.
I'm running OpenWRT op my deco M4R v2 and it works.
I only have a lot of stability issues with OTA on my esp devices(2.4Ghz, ESPHome and Tasmota)
OTA times out a lot of times and then it takes me some work to get the devices to work again.

I tried replacing ath10k-firmware-qca9888-ct with ath10k-firmware-qca9888 and kmod-ath10k-ct with kmod-ath10k but that made is worse because then it always timed out.

now I'm using ath10k-firmware-qca9888-ct-full-htt which seems to reduce the issue. Still I would like to have it fully go away. the original TP-link firmware doesn't have those issues. it has other issues, but I rarely had OTA Time outs. is there something I can do to improve the stability? or is there anyone else having those issues?

Hi @KinteLiX, thanks for your work on this and the clear instructions.
I am trying to apply them to my Deco M4R V2 units, but something is going wrong:
I can get to the recovery WebGUI, but a few seconds after the Firmware Upgrade starts (8%?) my (wired) connection seems to drop, the Deco reboots and nothing happens...
in Wireshark I can see that it starts sending data, then suddenly it starts spitting out erronous TCP packet information. the Deco seems to reboot, Yellow light turns ON, takes a while and turns RED.

On wireshark I see no data with the Deco as source whatsoever. Both static and Dynamic IP on my laptop don't work, I cannot see any wireless SSID originating from the device, and hooking up the deco to a DHCP server also doesn't seem to be doing anything.
to make sure windows isn't dropping my connection (something I had with upgrading a Mikrotik device) I tried putting an unmanaged switch in between, but the same happens to the Deco.

Any idea what is going wrong here?

Is there a specific original TP-Link firmware Image I should flash first? Can I hook up to any of the two LAN ports?

thanks!

Hi,
The first thing you can try is flashing a normal firmware from the TP-Link website to see if it's the router that's refusing the debug firmware.

Despite getting the router upstream, I'm not the most knowledgeable person in this forum. I don't know the inner workings of the stock firmware.

Other people have also reported issues with flashing the device (possibly with newer firmwares?). I am not sure why this happens, it could be that TP-Link somehow managed to block it.
What I do know is it can't be the bootloader at fault here because u-boot upgrades are not enabled.

If the current method doesn't work on newer firmwares, an exploit could be used. Over on the S4 forum, the person who made the PR for the router found an exploit in the bootloader which enables TFTP temporarily which then pulls and flashes a firmware without any checks.

I went over there to ask about that exploit and @naf was kind enough to create one for the M4R too.

We're now able to flash OpenWrt to a stock Deco M4R v1 and v2 without needing any debug firmware. Tried it on one of my devices and works great.

Just follow these instructions:

  1. Download the exploit from here: OpenWrt support for Deco S4 - #103 by naf
  2. Download the initramfs version and the sysupgrade version of the current firmware from here:
    https://downloads.openwrt.org/releases/22.03.2/targets/ath79/generic/openwrt-22.03.2-ath79-generic-tplink_deco-m4r-v1-initramfs-kernel.bin
    https://downloads.openwrt.org/releases/22.03.2/targets/ath79/generic/openwrt-22.03.2-ath79-generic-tplink_deco-m4r-v1-squashfs-sysupgrade.bin
    Or check for newer versions than 22.03.2 here: https://downloads.openwrt.org/releases/
  3. Install and run a TFTP server. On Windows I use OpenTFTPServer from here: https://sourceforge.net/projects/tftp-server/
    And make sure that no antivirus software or firewall is blocking incoming TFTP requests on port 69.
  4. Rename the initramfs firmware file to "initramfs-kernel.bin" and place it into the folder of the TFTP server.
  5. Set the IP address of the wired interface of your computer to "192.168.0.2" and directly connect said interface to one of the RJ45 ports of the Deco M4R.
  6. Use a SIM tray tool or anything else thin like a toothpick to press down the reset button that is at the bottom of the M4R and keep it pressed. Now power on the M4R or power cycle it to hard-reboot it. Don't let go of the reset button until the LED turns off.
  7. Open http://192.168.0.1 on your computer.
  8. On that page choose the exploit file and then press "Upgrade". If you monitor your network traffic with task-manager you should see a blip from the exploit uploading and then a short burst of 2-3 seconds while the exploit pulls the initramfs file from the TFTP server. Meanwhile the webpage will tell you that the upgrade failed, but only because the M4R is now booting the initramfs firmware and isn't responding to the webpage anymore.
  9. The M4R should now be blinking while the initramfs firmware is booting up.
  10. Set your wired network interface to "auto" or "dhcp" or whatever it's called and wait for it to automatically get assigned an IP from the M4R. You might have to pull and replug the network cable for that to work.
  11. Go to http://192.168.1.1 and simply log in without any password.
  12. On that status page go to "System->Backup/Flash Firmware" at the top.
  13. Click on "Flash image...", select the sysupgrade file and flash it.
  14. Wait for the M4R to flash the sysupgrade and reboot and then you should have a Deco M4R with a working OpenWrt firmware flashed to it.
9 Likes

This is great! I guess the next thing to do is to create a wiki page for the device.

I'll try it over the weekend and share my results here.

The "you" was more directed at the person finding these instructions and trying them out. But if you do have a v1 then yes, please, try it.

I wonder if it works the same for the v3.

That's awesome news but I'm still confused at how the procedure now changed from what it was previously. What is now the right method to push that firmware in a stock M4R V1?

I'm used to going thru proper wiki's for each specific devices and that endless thread confuses me a bit.

Proper work costs proper money and so far none of us had the motivation to create the wiki page for free.

I suggest you keep reading the thread. You'll find my newest instructions to flash your device eventually.

Greetings,
thank you so much for your effort! :slight_smile: What about rolling back to original TP-Link firmware? what do we have to do?

Press the reset button, power on the device, surf to the recovery webpage and flash a stock firmware you like and isn't older than the one you had before flashing OpenWrt for the first time.

OpenWrt doesn't touch the "config" partition, so the device should still have all the settings you left it with when you switched to OpenWrt.

Hi @KinteLiX , I figured out what was wrong.
Maybe some things to add to the instructions:

  1. The TP-Link DecoM4 units need to be connected to the internet for it to work correctly with the original firmware (can be directly or behind another router)
  2. The TP-Link DecoM4 units need to be set up correctly (and completely) through the Deco app, otherwise you will not be able to reach the web interface (to flash OpenWRT, the recovery/bootloader web interface works correctly)
  3. To reset a DecoM4 unit to factory default (if you want to set it up in the Deco app) you have to press the reset button, while it is up and running. I still haven't figured out when and how long exactly this needs to be done. I went through multiple boot cycles, waiting for the yellow LED, Red LED, and suddenly it started blinking Blue (ready for set up).
  4. After installing OpenWRT I did have some problems getting an IP address assigned on my laptop at first, still not sure if I just didn't wait long enough or that a few reboots solved it...
    the rest of the installation is a breeze :wink:

I have set the units up as dumb AP, and am reaching 300-325Mbit/s down and up. Reading some other threads, the QCA9563 seems to be just a tad too slow to do more, and overclocking could help here.
I still don't fully understand what is causing the CPU to be overloaded? reading the datasheets of both the QCA9563 and the QCA9886, I expect (but not fully sure) that the whole Wifi protocol and AES (WPA2) is done in hardware and doesn't need cpu power, or is part of this functionality not available in OpenWRT?

Also reading the QCA9563 datasheet, it seems possible to overrule the pll configuration, and thus overclock the device, however, with the current builds, /dev/mem is not available so I cannot peek/poke those registers. also the pll configuration is available in the QCA956X.dtsi devicetree file, but the part is not in the qca9563_tplink_deco-m4r-v1.dts (and therefore?) not accessible in Linux. I currently don't have a development environment set up, would someone be able to provide a build, or tools to access these cpu mapped registers? this seems like a safer way than hex-editing the uboot bootloader (as is done in the thread about the Archer C6 V2). Still even if I can override these PLL settings, I am not entirely sure if switching during runtime is possible (while keeping everything stable).

Hi, I've added a notice to have the device set up with the app as a pre-requisite. As for the speed problems, it is a known issue. Software flow offloading is broken in 22.03 with PPPoE. Wireless was slower for me even with the unofficial 21.02 builds before mainlining.

Very late response, life got in the way. I've tried it and it didn't work, the router did nothing and the TFTP server kept idling. I've tried Windows and Linux, followed the instructions to a tee. Seems like there is some difference between the bootloaders of V1 and V2.

You could send @naf your bootloader partition of the V1 and ask him if he can have a look at it. Maybe some small detail needs to be changed in the exploit to make it work for the V1.

1 Like

Thanks for pointing me to that issue. I guess that is something else than I am getting, as I am not using PPPoE,
My main router is an Edgerouter 6p, running stock firmware. The Decos are all put in a simple dumb AP configuration.
Ipv4 only, firewall and dnsmasq all switched off. Not sure the sw offloading feature then actually still does something.

As read in the overclocking thread, it seems the wireless throughput is bottlenecked by the Qca9563 running at 775Mhz. Overclocking seems possible by hacking/patching the bootloader and overwritting the Uboot in flash... Which means overwriting the TPlink uboot for the M4r, which I am hesitant of doing.

I expect switching clock speed after boot can be possible, but I need to be able to access these cpu memory mapped registers...

Still, that doesn't explain why stock firmware reaches higher throughout speeds for wireless to lan transfers. And what exactly is consumit these cpu cycles.

There is also Qualcomm Fast Path: Qualcomm Fast Path For LEDE

There is a github repo for the Deco P9 (That's an M4R with additional Powerline board) that has Qualcomm Fast Path patched into it: Deco P9 switch config - #17 by dietcoke73

I haven't looked into this myself but maybe it's worth checking out for you to get more speed out of your deco.

Thanks,

That thread mentions some interesting things. Though as far as I can tell, the Fastpath patches also only fix routing throughput in the firewall/nat. Not switching througput.
@quarky does mention a patch for ath10k wifi tx encap offload, that does sound like it can help, but I cannot find any repo/link/source/info on that patch... Anyone here has some info on it?

Just received my Deco M4R hoping I could flash them to openwrt, seems mine are on hardware version v4.0.
Although my knowledge in this subject is lacking, I'm fully prepared to solder and/or potentially brick my devices to try and get them to openwrt.
Is there someone willing to assist in this or should I just send them back and get something that's already supported?