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

Would you please send the instruction you follow in order to flash openwork. i don't want to brick it and if you can provide a version that work on your router.


it only works apparently with EU version. I have the ES version and I can't install it.



Hello, there!

I also recently got V6 of this Router and installed 19.07.7 on it by following the installation instructions you mentioned (during these steps for cutting boot loader etc from vendor fw I used tp-link fw for V6). Then I played around with several mt76-based drivers for no luck, so I went back to stock fw. What was really interesting: All the settings I had done in the stock firmware were there, nothing was erased! The OEM-WebGUI-password was set, the time synchronisation settings (using my primary router as ntp-server), everything I checked was exactly like before. As I usually don't play around much with vendor fw besides having a short glance over stock functionality I can't really tell, if this is a real difference to V4, as I never reverted my V4 back to stock.

Then I searched for TechData about V6 in all the well-known sources, but was not able to find out what 5-GHz-Radio is built into V6. Not even an FCC-ID (also searched for an probably imaginary A5 v6 in an act of pure guessing)... So I opened the router and made some photos. I found an MT7628AN + MT7613BEN. The latter ist different from V4/V5, so I checked for devices with this in the TOH and found some in SNAPSHOT and some hints in the forum that indicated, that mt7615e was the driver to use for this. So I decided to have another try with 21.02.0-rc3, driver mt7615e and Firmware mt7663-firmware-ap. With this combination the 5-GHz became accessible. I made an experimental image using imagebuilder with profile for V4 including luci.

Obvious issue with these images so far seems to be the WLAN-LEDs, they just won't stop blinking after WLAN is activated. Also I cannot tell, if DFS ist working for 5-GHz. And of course the device reports itself as V4, as I didn't create an extra profile for V6.

If you wanna try @samba2 @tchargui you're welcome!

THIS is a link to a DropBox-Folder with 4 Files in it:

  • experimental-archer-c50-eu-v6-factory.bin - for use in TP-Link WebGUI, based on 21.02.0-rc3 for C50v4
  • archer-c50-eu-v6-sysupgrade-back2stock.bin - for going back to TP-Link-FW via LUCI / SSH-Sysupgrade
  • experimental-archer-c50-eu-v6-factory-for-tftp(name tp_recovery).bin - same as first, but for use with TFTP-method
  • archer-c50-eu-v6-tftp-back2stock(name tp_recovery).bin - for going back to stock via TFTP


Hi, again!

I managed to solder some pins to the serial header, located between the blue WAN port and the flash chip. I only connected the left 3 pins Rx,Tx and Gnd. I guess, the outer right should be 3v3, but I didn't connect any cable to it. I used 115200 - 8N1 settings. I posted the OEM Bootlog at PasteBin.

1 Like

Hi again!
The WLAN-LEDs stop blinking after a while and get lit solidly. I guess, they might work correctly and the blinking is for some good reason which I just don't see... Maybe DFS-sensing or something like that :sweat_smile: So tending to call it "works as it should".
After some reading of bootlogs from V4 and my own V6 I see same flash partitions and started creating a hardware profile locally using the DTS-file of V4, as I expected GPIOs/LEDs and Flash to act just identically, which seems to be the case (besides V6 has just 5 LEDs, WPS-LED ist missing). I can change color of the WAN-LED between orange and green, WAN, LAN, Power, WLAN-5 and WLAN-2 seem to work as expected. WLAN- and RESET-Buttons work, too. I created this profile on top of OpenWRT 21.02.0-RC4 with updated mt76-driver. In some files (, etc.) where there are case decisions made for networking, leds etc. I added the V6 to be handled the same ways as V4. The MAC Address of BR-LAN matches the one at the label of the bottom of the device. WLAN-2 an WAN also have this same MAC, only WLAN-5 is different. Is this expected? If not, what should / can I do about this? I must admit, that this kind of work is not one of my talents, but I'll do my very best. :sweat_smile:

My concerns regarding DFS on the 5GHz mainly foot on
this thread in the forum. Reading the syslog I noticed that after configuring the 5GHz it wouldn't start due to initialization failure related do DFS, while showing ENABLED state in LuCIs wireless section. WPS didn't work then either (using wpad-openssl). Restarting the wireless device couldn't resolve this, but rebooting the whole router did. So after configuring the AP it is a good idea to reboot the router. Indeed I tend to call this a MT7613-driver issue, not a "create-support-for-C50-V6"-issue... When the 5GHz ist up, it works quite well for my "home use", meaning: I did some speedtests, but no excessive stress tests with Iperf for several hours or something like that.

What can I do next to help creating Support for the V6? What has to be reviewed, tested, handed over to somebody with more knowledge and competence?

This thread in developer's part of the forum is closed, so I cannot provide these information there to possibly draw somebodys attention. :sweat_smile:

Best regards!

Today I needed several reboots to get 5GHz up and running. Syslog looked like this:

Mon Aug  9 12:39:12 2021 daemon.notice hostapd: wlan1: ACS-COMPLETED freq=5660 channel=132
Mon Aug  9 12:39:12 2021 daemon.notice hostapd: wlan1: interface state ACS->HT_SCAN
Mon Aug  9 12:39:13 2021 daemon.notice hostapd: wlan1: interface state HT_SCAN->DFS
Mon Aug  9 12:39:13 2021 daemon.notice hostapd: wlan1: DFS-CAC-START freq=5660 chan=132 sec_chan=1, width=1, seg0=138, seg1=0, cac_time=60s
Mon Aug  9 12:39:13 2021 daemon.err hostapd: DFS start_dfs_cac() failed, -1
Mon Aug  9 12:39:13 2021 daemon.err hostapd: Interface initialization failed
Mon Aug  9 12:39:13 2021 daemon.notice hostapd: wlan1: interface state DFS->DISABLED
Mon Aug  9 12:39:13 2021 daemon.notice hostapd: wlan1: AP-DISABLED

Edit 2:
Seems like channel 149 is more likely to succeed than others. I might change to a manually chosen channel instead of AUTO...

Mon Aug  9 12:43:16 2021 daemon.notice hostapd: wlan1: ACS-COMPLETED freq=5745 channel=149
Mon Aug  9 12:43:16 2021 daemon.notice hostapd: wlan1: interface state ACS->HT_SCAN
Mon Aug  9 12:43:17 2021 daemon.notice hostapd: WPS: Converting push_button to virtual_push_button for WPS 2.0 compliance
Mon Aug  9 12:43:17 2021 kernel: [  303.910064] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
Mon Aug  9 12:43:17 2021 kernel: [  303.916821] br-lan: port 2(wlan1) entered blocking state
Mon Aug  9 12:43:17 2021 kernel: [  303.922260] br-lan: port 2(wlan1) entered forwarding state
Mon Aug  9 12:43:17 2021 daemon.notice netifd: Network device 'wlan1' link is up
Mon Aug  9 12:43:17 2021 daemon.notice hostapd: wlan1: interface state HT_SCAN->ENABLED
Mon Aug  9 12:43:17 2021 daemon.notice hostapd: wlan1: AP-ENABLED

Been lurking the topic of c50 v6 support for a couple of months and can attest that the build from @Marssl is closest to an expected experience I've tried.

I can also second the fact that the 5ghz drops out for all available clients after a certain time, and a reboot of the system seeming to be the easiest fix.

The weird thing is that the same symptoms manifests in the 2.4ghz radio too

So essentially both radios cuts out at the same time, but I have yet to determine any specific culprit such as load on the system or the like.

1 Like

Thank you for commenting on my build @TestingForSolutions8 . :smiley:

I just added 2 more files to the dropbox folder:

  • owrt21.02.0rc4-experimental-c50-v6-sysupgrade.bin
  • owrt21.02.0rc4-experimental-sqm-c50-v6-sysupgrade.bin

That is for upgrading to 21.02.0-RC4 which includes a MT7615e driver update. I think it improves the 5GHz quite a bit. You have to force update the firmware using this file as I created a V6 hardware profile for this, while the previous build thinks of itself as a modified V4. I also didn't include the alternative firmware for wlan-client-mode, as most users won't need it and it uses up almost 0.8MB of flash space. The second one includes SQM.

HERE is the link again, for simplicity


Thank you for providing a second test file @Marssl :grinning: I have it updated now and once again deployed as the main router of the household to test in a real world scenario.

Will report back my findings after seeing an organic flow of users and devices having been through the network

I'm also going to throw in an intentional stress test on a mix of 2.4- and 5hz devices later when I have the time.


Hi @Marssl .. i´m testing it also... Had some issues with vlan bridging with wireless in the last version.. but i´m new to version 21 so it could be me..

Will follow up later on.

So I have an update after having tested for a few days. The router works splendidly with all the features one can expect at this point, however it does experience what I might call hard stop issues at times. These being the following:

  1. Router has restarted itself after using the 5ghz radio in certain scenarios, with no discernable difference to the type of load. This has not yet occurred using the 2.4ghz radio, but I wouldn't rule it out as never being able to happen, however at this point it does seem more unlikely on the 2.4ghz radio.
  2. Router has gone into a state total unresponsiveness. The LEDs where off, and wasn't reachable from either wifi or ethernet. Only solution being a restart by physically pushing the power button on the router. My guess in this case would be a kernel panic, but I can't back that up with hard data.
  3. Both the wireless radios does at some point after an uptime period of about 2 days exhibit odd behaviour. Latency tolerant operations work fine when the behaviour occurs, however lower latency operations like sending input data over local network does not (This being for instance sending kb+m inputs). This issue isn't fixed by restarting the radios or disconnecting clients, but rather the only solution being a restart of the router itself.
1 Like

Hi @Marssl any possibility of starting an official TP-Link Archer C50 V6 page like the ones setup for V5 here: You could put details there to help everyone with the newer V6 version of this router.

1 Like

I think I've found the clue to the symptoms for this specific issue with this snippet from my syslog:

Tue Aug  3 13:24:31 2021 kern.warn kernel: [244103.956537] sched: RT throttling activated

This always pops up right before the system starts halting in bad ways, and as far I understand it it's a feature of the linux kernel that is triggered as mechanism to protect against another fault in the system. Here is is little snippet on RT throttling from the linuxfoundation docs page:

Programming failures in real-time applications can cause the entire system to hang. Such a failure could act like a call of a while(true){} loop. When the real-time application has the highest possible priority and is scheduled with SCHED_FIFO policy, no other task can preempt it. This leads to the system blocking all other tasks and scheduling this loop with a CPU load of 100 percent. Real-time throttling is a mechanism to avoid such situations by limiting the execution time of real-time tasks per period.

Direct link

However this only tells me that the kernel went into this fail-safe mode triggered by some other issue, but the logs at the time didn't have a anything peculiar before or after the snippet I posted. However I do have a more recent syslog and it's accompanying kernel log with the same RT throttle trigger.

Thu Aug 19 12:44:42 2021 daemon.notice hostapd: nl80211: nl80211_recv_beacons->nl_recvmsgs failed: -5
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.169264] mt76-tx phy1: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null)
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.178523] CPU: 0 PID: 700 Comm: mt76-tx phy1 Not tainted 5.4.137 #0
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.185071] Stack : 80640000 805e1420 00000000 00000000 805e0518 82c09aec 83d6b8a0 8061ed63
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.193555]         80587874 000002bc 807733bc 00000000 02596182 00000001 82c09aa0 96391d5c
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.202036]         00000000 00000000 807a0000 00000000 30232037 000000d8 65746e69 2e352064
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.210527]         00000000 0000000c 00000000 0002b95b 00000000 8058d6f0 00000000 00000000
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.219008]         00000000 00000000 02596182 00000a20 00000000 802bbabc 00000000 80770000
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.227490]         ...
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.229965] Call Trace:
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.232474] [<80009c90>] show_stack+0x30/0x100
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.237006] [<801125f0>] warn_alloc+0xb8/0x130
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.241523] [<80112fe8>] __alloc_pages_nodemask+0x980/0xcc8
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.247194] [<801135ec>] page_frag_alloc+0x1a0/0x1cc
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.252242] [<80310628>] fe_poll+0x4d0/0x8e8
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.256596] [<8035b09c>] __napi_poll+0x3c/0x10c
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.261199] [<8035b2f8>] net_rx_action+0xfc/0x270
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.265989] [<804f9048>] __do_softirq+0x110/0x298
Thu Aug 19 12:44:51 2021 kern.warn kernel: [  257.270778] [<80026c18>] do_softirq.part.14+0x60/0x84
Thu Aug 19 12:44:51 2

kernel log:

[  163.139596] sched: RT throttling activated
[  257.169264] mt76-tx phy1: page allocation failure: order:0, mode:0xa20(GFP_ATOMIC), nodemask=(null)
[  257.178523] CPU: 0 PID: 700 Comm: mt76-tx phy1 Not tainted 5.4.137 #0
[  257.185071] Stack : 80640000 805e1420 00000000 00000000 805e0518 82c09aec 83d6b8a0 8061ed63
[  257.193555]         80587874 000002bc 807733bc 00000000 02596182 00000001 82c09aa0 96391d5c
[  257.202036]         00000000 00000000 807a0000 00000000 30232037 000000d8 65746e69 2e352064
[  257.210527]         00000000 0000000c 00000000 0002b95b 00000000 8058d6f0 00000000 00000000
[  257.219008]         00000000 00000000 02596182 00000a20 00000000 802bbabc 00000000 80770000
[  257.227490]         ...
[  257.229965] Call Trace:
[  257.232474] [<80009c90>] show_stack+0x30/0x100
[  257.237006] [<801125f0>] warn_alloc+0xb8/0x130
[  257.241523] [<80112fe8>] __alloc_pages_nodemask+0x980/0xcc8
[  257.247194] [<801135ec>] page_frag_alloc+0x1a0/0x1cc
[  257.252242] [<80310628>] fe_poll+0x4d0/0x8e8
[  257.256596] [<8035b09c>] __napi_poll+0x3c/0x10c
[  257.261199] [<8035b2f8>] net_rx_action+0xfc/0x270
[  257.265989] [<804f9048>] __do_softirq+0x110/0x298
[  257.270778] [<80026c18>] do_softirq.part.14+0x60/0x84
[  257.275908] [<80026cfc>] __local_bh_enable_ip+0xc0/0xc8
[  257.281363] [<83731d04>] ieee80211_next_txq+0x174/0x28c [mac80211]
[  257.287742] [<835165ac>] mt76_tx+0x268/0x56c [mt76]
[  257.292713] Mem-Info:
[  257.295038] active_anon:399 inactive_anon:8 isolated_anon:0
[  257.295038]  active_file:1712 inactive_file:1335 isolated_file:5
[  257.295038]  unevictable:0 dirty:0 writeback:0 unstable:0
[  257.295038]  slab_reclaimable:379 slab_unreclaimable:2263
[  257.295038]  mapped:915 shmem:23 pagetables:72 bounce:0
[  257.295038]  free:766 free_pcp:13 free_cma:0
[  257.327292] Node 0 active_anon:1596kB inactive_anon:32kB active_file:6848kB inactive_file:5340kB unevictable:0kB isolated(anon):0kB isolated(file):20kB mapped:3660kB dirty:0kB writeback:0kB shmem:92kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[  257.350043] Normal free:3064kB min:16384kB low:18432kB high:20480kB active_anon:1596kB inactive_anon:32kB active_file:6848kB inactive_file:5340kB unevictable:0kB writepending:0kB present:65536kB managed:58176kB mlocked:0kB kernel_stack:392kB pagetables:288kB bounce:0kB free_pcp:52kB local_pcp:52kB free_cma:0kB
[  257.377873] lowmem_reserve[]: 0 0
[  257.381240] Normal: 88*4kB (UME) 39*8kB (UME) 16*16kB (UM) 17*32kB (UM) 5*64kB (U) 0*128kB 1*256kB (U) 0*512kB 1*1024kB (U) 0*2048kB 0*4096kB = 3064kB
[  257.394947] 3072 total pagecache pages
[  257.398751] 0 pages in swap cache
[  257.402106] Swap cache stats: add 0, delete 0, find 0/0
[  257.407404] Free swap  = 0kB
[  257.410329] Total swap = 0kB
[  257.413243] 16384 pages RAM
[  257.416081] 0 pages HighMem/MovableOnly
[  257.419970] 1840 pages reserved

From glancing through it it does seem like some sort of memory issue related to the wifi, but I'm not all that adept at gleaming issues from logs so take that with grain of salt.

This was all running the router as the the primary router/gateway/access point of my entire household using the build with sqm.

To round of this post I have between now and when the logs were taken reinstalled openwrt on the device with the non sqm build from @Marssl and now only running at as an access point to test the wireless radios in more of a vacuum and I haven't had any issues yet using it in this configuration.

The particulars of what I've experienced so far could of course be because of a bad install performed by me. Are you @Marssl and @hjsimoes experiencing something similar in your testing?

@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.