TP-Link Archer C50 (EU) V6.0 - 5 GHz interface not present

@Marssl: How can I install new package?

  • The installed version of package kernel is not compatible, require 5.4.137-1-81b5fa8a… while 5.4.137-1-0d541bae… is installed.

Hi @Marssl, is there any way you can share the files you created for v6 via github or something? I might then try porting the official release. I am using the final firmware (sqm) for about a day now, and everything seems stable.


I have been running on a C50 (CA) V6.0 for about a month now. The sysupgrade bricked my router, however when I ran the tftp back2stock recovery, I ended up running openwrt. I am a bit new a trouble shooting this, so I likely made a mistake.

I have run into a problem where it will disconnect the devices, but since I am running it as an access point the computers got really confused, and did not want to jump back on to the primary router. Seeing that rebooting solved the issue, I just use cron to reboot every night and have been running without a problem.

Just sharing my experiences on this firmware, with a different local of hardware. I also get faster throughput than stock.

thanks for the work you put into this.


Standard flashing through tplink web interface bricks the unit.
However it restores easy by using the tftp version back to normal firmware.

Reflash through TFTP method the openwrt file for tftp worked fine.

So for those coming to this firmware just do the FTFP flash of

experimental-archer-c50-eu-v6-factory-for-tftp(name tp_recovery).bin
it works

thanks goes to all involved in making this work

Built a snapshot for v6 using v4 profile in imagebuilder. Only replaced wpad-basic-wolfssl to wpad-mesh-wolfssl, and removed a few ipv6 packages, which you can install if you want. 2.4g, 5g, LEDs, ethernet and everything works as expected. Uploads are a bit flaky as it seems.

Use this image in sysupgrade only. Force install if you have to since the device will think itself as v4 in this build, and preferably remove all existing configs, since they may conflict with the new build.


1 Like

Intermittent Wifi disconnect ( Wifi light stays fully on instead of blinking and the Wifi interface in Luci shows ? even after restarting Wifi using any method, and the SSID disappears from the network, reboot solves it ) issue after a few hours ( 8-12 hours ) with the same MCU messages in the logs and no error if disabling WMM

MT7628 OpenWrt 21.02 - MCU message 08 (seq 1) timed out

This sees to be a regression Wifi issue ( not present in 19.07 ( unconfirmed report ) occurs in 21.02 )

Marssl: 21.02.0rc4 - Less problematic after all package updates

subhranil: 2022.02.08 ( 21.02.1 ?) - Problem exists even after all package updates

Official Archer C50v4 21.02.2 firmware running on the v6 ( don't require 5ghz) - Problem exists even after all package updates

Note, have htmode40+ and legacy ( required for standardisation ) may not be related as reports of intermittent wifi issues without htmode40+ and legacy were still probably there ( unconfirmed as to frequency of the same etc )

I also have the TP-Link Archer C50 (ES) V6.0 device. I tried using a V4 image using the approach here, using the Web UI to load it, but it rejected it.

However looking at the TP-Link official image files, they are completely different for the EU and ES versions of the device. The EU image BIN file is 7930368 bytes, and the ES image BIN file is 2183572 bytes. So I think they're ripping us off in the ES regions and selling a cut-down device. Maybe it even has less flash and/or RAM, which would likely make it useless. So I'm giving up with this device. I'll use it as an access point elsewhere and look for some other router to put OpenWRT on (which I need for load balancing and monitoring) -- unless anyone has any other ideas.

I can update that the official Archer C50v4 firmware update 21.02.3 for the v5 too, but using for the V6 ( remember no 5ghz required just stability on the 2.4 ghz ) WITH WMM DISABLED updates fine using sysupgrade and shows no intermittent Wifi issues.

Side note: Since SQM is already installed, the so called WMM "QOS" feature may not be an ideal piece of code and there should be a way to enable "bn", ( WMM disabling just enabled "ag" at upto 20 MBPs tested ) and not try to do any QOS stuff on the Wifi interface. Funny that all OpenWRT routers with "abgn" and WMM enabled never really performed more than 20 Mbps ( even with WAN at 100 Mbps ) in six months of testing. So disabling WMM wasn't such a big deal when comparing Openwrt and Openwrt, even better at a steady 20mbps when assumedly WMM was not interfering with the speeds.

Another option is to try and test the official MTK wifi drivers:

Do not have the werewithal currently. Although it might be a good time to investigate Open Source code and developer team psychology.

Linux has been plagued with the "reputable developer syndrome" as in their code is only allowed to be built on and patched ever so slightly always tiptoeing around "developer reputation" and the like.

If we look at the angle that the original Openwrt open source driver was "booked for eternity" with a fixed amount of code, be it good intent or sheer inability to rewrite equally performant code in open source, or even employer and law forcing open source to write non-performant code so as not to appear to be copying the official code, be it closed or open, we have a problem.

It might be time for an open contest to invite corporates to donate code chunks as replacement for large sections of the code and a free for all forking culture so that main-line does not get booked by non-performant good intention or performant but commercially motivated bad intention code.

Basically the open source MTK wifi driver needs careful scrutiny and updating and this statement by Openwrt ( ): "

(Aug 2020): The cause for poor 2.4 GHz range experienced with some C50 v4 and probably C50 v5 models has been found. Also reports of random reboots OpenWrt forum Bug Report 2781 Fixed 2.4 GHz poor wifi speed (Feb 2021) from 19.07.7 mt76: mt7603: add additional EEPROM chip ID

certainly doesn't mention the WMM issue and certainly isn't all the problem with the MTK Openwrt driver.