Could you describe the issues you're having?
The VPN does not start correctly after a reboot.
when i make settings change it does not save, which i have traced to this error:
Your JFFS2-partition seems full and overlayfs is mounted read-only. Please try to remove files from /overlay/upper/... and reboot!
Maybe you could remove some things from the image. (For instance luci and use the command-line instead.)
I can confirm that the RU variant also works. I updated the commit message to make this explicit. Here is the current PR: https://github.com/openwrt/openwrt/pull/13547
I verified that the MAC addresses are matching with the ODM firmware for each interface, so that is all good!
Yes, the device I have here is black, and looks just like the one in the C54 picture. It says on the back panel "Archer C50(ES) Ver:6.0". But as you say it may be confusingly badged for Latam markets.
1 Like
Thanks for checking! Sorry to hear that TP-Link seems to be somewhat dishonest when it comes to these matters. I added a note to the wiki page on the Archer C50: https://openwrt.org/toh/tp-link/archer-c50
Let me know what you think of this message, possibly you could adjust it. For more information you might want to read all the information available on the Archer C54.
Some results from my testing. I did not face any 5 GHz crash but I did face a crash that caused all wired connectivity to break (only WiFi was still working):
[64116.858855] ------------[ cut here ]------------
[64116.863575] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x2d8/0x2e0
[64116.872047] NETDEV WATCHDOG: eth0 (mtk_soc_eth): transmit queue 0 timed out
[64116.879127] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7615e mt7615_common mt7603e mt76_connac_lib mt76 mac80211 lzo cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 lzo_rle lzo_decompress lzo_compress libcrc32c hwmon crc_ccitt compat sha512_generic seqiv jitterentropy_rng drbg hmac cmac crypto_acompress leds_gpio gpio_button_hotplug crc32c_generic
[64116.946340] CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.132 #0
[64116.952359] Stack : 00000000 00000000 80c0bdfc 80860000 806a0000 805fc214 806a22a0 806a1e23
[64116.960884] 808633b4 00000000 00000000 80061984 805f5964 00000001 80c0bdb8 438b51e5
[64116.969405] 00000000 00000000 805fc214 80c0bc50 ffffefff 00000000 00000000 ffffffea
[64116.977921] 00000000 80c0bc5c 00000123 806a8238 80860000 00000009 00000000 8041792c
[64116.986440] 00000009 00000000 00616089 80715d94 00000018 8032e17c 00000000 80860000
[64116.994960] ...
[64116.997445] Call Trace:
[64116.999928] [<80006e4c>] show_stack+0x28/0xf0
[64117.004378] [<80026060>] __warn+0x9c/0x124
[64117.008546] [<80026174>] warn_slowpath_fmt+0x8c/0xac
[64117.013601] [<8041792c>] dev_watchdog+0x2d8/0x2e0
[64117.018391] [<80071e0c>] call_timer_fn.constprop.0+0x1c/0x8c
[64117.024174] [<80072210>] run_timer_softirq+0x2f4/0x368
[64117.029407] [<8056a6e4>] __do_softirq+0x10c/0x2c4
[64117.034190] [<80002790>] except_vec_vi_end+0xb8/0xc4
[64117.039243] [<8056a48c>] r4k_wait_irqoff+0x18/0x24
[64117.044109] [<8056a53c>] default_idle_call+0x20/0x3c
[64117.049161] [<800516ec>] do_idle+0x7c/0xf0
[64117.053330] [<800519e0>] cpu_startup_entry+0x18/0x28
[64117.058374] [<8072fe50>] start_kernel+0x6ec/0x720
[64117.063168]
[64117.064677] ---[ end trace 623441dde8984f3b ]---
[64117.069378] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
[64117.075656] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:00000057
[64117.081764] mtk_soc_eth 10100000.ethernet eth0: tx_ring=0, base=020d8000, max=1024, ctx=924, dtx=871, fdx=871, next=924
[64117.092722] mtk_soc_eth 10100000.ethernet eth0: rx_ring=0, base=0214c000, max=1024, calc=640, drx=641
[65017.293022] rt3050-esw 10110000.esw: port 0 link down
[65017.299078] br-lan: port 1(eth0.1) entered disabled state
[65021.239726] rt3050-esw 10110000.esw: port 0 link up
[65021.245353] br-lan: port 1(eth0.1) entered blocking state
[65021.250875] br-lan: port 1(eth0.1) entered forwarding state
[65026.854923] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
[65026.861235] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:00000057
[65026.867376] mtk_soc_eth 10100000.ethernet eth0: tx_ring=0, base=020d8000, max=1024, ctx=586, dtx=1, fdx=1, next=586
[65026.877990] mtk_soc_eth 10100000.ethernet eth0: rx_ring=0, base=020c4000, max=1024, calc=993, drx=994
[65036.854895] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
[65036.861224] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:00000057
[65036.867354] mtk_soc_eth 10100000.ethernet eth0: tx_ring=0, base=020d8000, max=1024, ctx=2, dtx=0, fdx=0, next=2
[65036.877614] mtk_soc_eth 10100000.ethernet eth0: rx_ring=0, base=0214c000, max=1024, calc=9, drx=10
[65046.854877] mtk_soc_eth 10100000.ethernet eth0: transmit timed out
[65046.861205] mtk_soc_eth 10100000.ethernet eth0: dma_cfg:00000057
This would seem to relate to the part of the hardware that's identical to the v4 and v5 models. Did anybody else see anything like this?
Note that a reboot solved the issue.
Hi all. The PR is still pending. I added the related information on the supported variants (EU & RU). Could anybody who tested this let me know if I can add their name and e-mail address as Tested-by?
Myself I have not experienced any more issues up to now letting the router just work. (The above issue happened specifically when I was updating settings.)
hello, i replied to the forum email i got also, not sure what is correct.
i have the v6 (CA) model, which i have not yet seen discussed.
have attached serial and have control of U-Boot and console, if needed.
am new to this, have cloned and am building openwrt now.
would you please advise the correct method to build your PR and install?
I did not see any response before this post, but we have your post here which is great! Welcome to the forum and great you want to test along!!
I just compared the firmwares available and it turns out that the CA and EU firmware are identical:
ef5cb6efa82ecbac86101f4d4a1d903f Archer_C50v6_CA_0.9.1_0.4_up_boot[211108-rel33223].bin
ef5cb6efa82ecbac86101f4d4a1d903f Archer_C50v6_EU_0.9.1_0.4_up_boot[211108-rel33223].bin
So everything should just work.
I do not see any attachments, but I guess they are not needed. Maybe you could add them to the wiki for completeness, more of such logs are collected there and there is currently no v6 bootlog: https://openwrt.org/toh/tp-link/archer-c50
Did you get my branch? Generally the commit will always apply fine against the latest main OpenWRT. The instructions to prepend the ODM bootloader to the OpenWRT image should work.
Edit: I just updated the PR with the CA model as I see no reason it would not work.
am not sure how to get your branch, am not familiar with github, beyond knowing how to clone.
You can either:
- Fetch pull requests if you have OpenWRT's repo as the remote: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally
- Add my remote as a second remote
- Clone my fork instead
- Get the patch and apply it with
git am: https://github.com/openwrt/openwrt/commit/af7e88f5b8b3fe9b96cc43597effa46d930ce623.patch
The note about C50 v6 (ES) being probably a C54 seems fine. I bought something more capable to run OpenWRT in the end. Thanks!
1 Like
Tested on newly buyed device v6, for few hours. Working like a charm, including WiFi 5 GHz, WMM enabled. Tested multiple devices. No hungs, no restart needed, no problems. Thanks...
1 Like
Great!! Possibly this 5 GHz issue was resolved in OpenWRT itself in the mean time. Which model(s) did you test with specifically? Maybe I could add you as with Tested-by to the commit?
Anybody else who tested, also please let it know if I can add your name & e-mail address in a Tested-by header. The PR is still open.
1 Like
I've got tested larger number of routers v4.2 EU and this new v6 EU. When I tested newly buyed v6, I compared stability and usability with one piece of router v4.2, which I have. Performace of 5 GHz WiFi was similar for this two routers on 100/100 Mbps WAN connection. I tested 3 different notebooks and 2 different mobile phones with wireless connections and 2 PCs on wired connection.
You can add my name and email in Tested-by header. No problem. Jaroslav Mikulík byczech@gmail.com
1 Like
Amazing you really tested a lot 
And I also saw your approval!
I had initially added a known issues note regarding 5 GHz crashes but I did not run into that either. Possible this was fixed already in OpenWRT, so I'll remove that note as well.
1 Like
Add my email.
Been running my build for over a week. No problems as far as I can tell, other than the tiny memory.
A bit surprised no one else has mentioned the space thing
1 Like
Thanks! I added your name and address too. Let me know if I did not do it correctly.
The device indeed does not have much free space. There is not much that can be done about it I guess. You would need to limit what you install or fetch something to /tmp and run from there at boot. The main advantage of these devices seems to be their very low power usage. In my situation the power adapter of the fiber module even has a higher voltage than the router's!