State of Archer C7 v2 in mid-2020

Longtime Archer C7 V2 here. OpenWrt 18 series works well with this router, but you need to consider that OpenWrt doesn't support the hardware switch on this router, so you are limited by the CPU of this router. Sharing with 5 or 6 users is just fine, but more than that, you will probably need to reset it every few days (or every day if you're using OpenWrt 19 series.). QOS can handle 50 Mbps just fine (Mine handled up to about 300Mbps with no probems. Anything beyond that will be beyond the CPU power of this router and you will experience problems)

I never got this router work consistently with the 19 series: Random disconnections, random freezes , random Wireless problems, dropped packets... In the end i just reverted to original firmware and i'm using a RPI4 to handle QOS, print server and a pendrive as network drive.

In your case, i think the best is to keep using the 18 series. Still stable and quite usable at your internet speed.

Could you please share your custom build of 19.07 ?
I plan to create a mesh with C7v2 and TD-W8970 in the future and have concern about C7v2 stability in such scenario...thank you in advance

@Catfriend1 Another request for your custom build info and the watchdog script. Thanks in advance.

Same here, I have several with friends and family and whenever I try to move to a 19.07.x build, I wind up reverting back to 18 due to wifi-related issues.

Agreed, this router needs to be paired with a physical switch to isolate local-to-local traffic and to not overwhelm the CPU in the C7. I use $20 8-port switches, so 7 available ports.

Interesting. Are you sure about this? I am using multiple C7's as combined "edge switches" and "AP's". All of them are wired to central router (thru WAN port, I untagged the ports so it is basically just a 5-port switch now) and have various stuff connected "locally" (on LAN1-4). Just for fun, I run iperf3 from LAN to WAN1 port (wired, PC to PC) and hit 900Mbit/sec w/o issues.

To my knowledge, is is fully fledged hardware switch and my measurments support that.

1 Like

My custom build, from official repo and stable 19.07.4 sources.

This was the way I took to build it on a 16 core machine, it needs a lot of free space (30 GB at least).

apt-get update
apt-get install -y build-essential libncurses5-dev gawk git libssl-dev gettext zlib1g-dev swig unzip time rsync python3 python3-setuptools
mkdir -p "/root/build"
cd "/root/build"
git clone
cd "/root/build/openwrt"
git checkout v19.07.4
./scripts/feeds update -a
./scripts/feeds install -a
make menuconfig
# Selections
## Target System (Atheros ATH79 (DTS))
## Subtarget (Generic)
## Target Profile (TP-Link Archer C7 v5)
## Firmware
### <*> ath10k-firmware-qca988x
### < > ath10k-firmware-qca988x-ct
## Kernel modules
### Filesystems
#### <*> kmod-fs-ext4
#### <*> kmod-fs-msdos
### Network support
#### <*> kmod-batman-adv
### USB Support
#### <*> kmod-usb-storage
### Wireless drivers
#### <*> kmod-ath10k
#### < > kmod-ath10k-ct
## LuCI
### Collections
#### <*> luci
## Network
### VPN
#### <*> openvpn-openssl
### <*> batctl-full
### < > wpad-basic
### <*> wpad-mesh-openssl
# cp "/root/build/openwrt/.config" "/root/build/.lastconfig"
# cp "/root/build/.lastconfig" "/root/build/openwrt/.config"
make -j 16
# make -j1 V=s
# Output
## /root/build/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/tmp
exit 0

I second this. My Archer's "hold up" a switched Gigabit client network "whilst" also being WiFi access points. Reaching rock solid max. ~ 100 MByte/sec. NAS transfer over the LAN switch.

@TopDog Here's the "wrtwatchdog" service script: Ath10k_pci 0000:01:00.0: SWBA overrun on vdev 0, skipped old beacon
I've updated the post to show how it's correctly put in /etc/rc.local for autorun and that "bash" must be installed.


Sorry, my bad. What is not supported is the "hardware NAT" (a.k.a. "Qualcomm FastPath" or "hardware flow offloading"). The Atheros QCA9558 processor is more than capable to route 1Gbps in software without major issues (Except the often reported 1.9x cpu usage from the router logs...) . Where problems arise is when the number of concurrent clients connected (in my case at least, YMMV) are more than 10 (See my post with details here: I need help on a router). The 19 series in this case was never stable on my case. The 15 up to 18 series was pretty OK to me (But, back then, i didn't had to route 500Mbps to more than 10 clients :wink: ), but since i have to manage around 12-14 clients, i need QOS and is QOS what makes things slow in this router.

1 Like

I believe your 2.4 WLAN is failing and you are mixing it up with "router" failing. In my experience, only thing that will "fail" in Archer C7 running OpenWRT is 2.4GHz WiFi. On my routers, 2.4 always failed after couple of days using multiple clients. On 18.x and 19.x versions, using different ath10k drivers, using no ath10k drivers at all etc. It never ever worked right. It is now disabled and I consider it faulty.

Routing/NAT always worked fine (within CPU constraints).

Also, why would you need QoS on 500Mbit line?

Nope, stock firmware works just nice for 2 weeks, no restarts, no wifi problems (no wifi interruptions, no IPTV freezes, no router freezes, no stuttening on games, no loss of connection between my RPI3 improvised repeater (19.xx had a lot of them for me, Openwrt 15 up to 18 worked great for me (although at the time was for 100Mbps, YMMV)). The problem is not the hardware. (At the very least, not in my case, although the router is being used as a dumb access point, the heavywork is done on a RPI4).

QOS?, That's what you need when you have around 6-8 clients using the internet at the same time in the night, with at least 2 of them doing torrents (i am one, and at the same time using netflix, and doing some light M$VPN Sessions to the work), other uses a Kodi box using IPTV, other plays fallout 76 (WTF!!??... oh well, i don't judge... too much :slight_smile: ) and there's another that does remote work using remote desktop clients. Not counting phones, or spotify, that the least of the problems. That's explain why they are paying more for the connection, but also the need for a better QOS manager, that's why, in my case, i use a rpi4, since i couldn't find a better router with OpenWRT support in my country. (Chile). Kinda bumpy supported nowadays, but better than what i had.

Then again, i think the OP would be more than happy using the 18.xx series for what he got. The Archer C7 is more than overkill at that speed. And at least from my experience, stay away from the 19.xx series. The headaches aren't worth it.

1 Like

I just joined to this forum to let you know that i have an Archer C5 that i converted to a C7 and flashed Archer C7 V3 art eeprom backup years back and that i have zero issues with what you are describing here. Everything works as advertised.

What firmware version?

I updated to the latest openwrt three days now but i was on various versions since

1 Like

Hello, I created an account just so I can thank you for posting this! I have had nothing but headaches for the past month or so due to the 2.4ghz dropping out at least once a day. We have 6 or 7 smart home devices that do not support 5ghz and after jumping between gargoyle and openwrt, I was on the verge of purchasing a separate access point until I came across your post.

I have been running your custom build along with your watchdog script on my Archer C7 v2 for the past few days and I have not encountered a single dropped connection so far! I am so grateful that you were able to share your script and build and I really wanted you to know how appreciative I am, so once again thank you!!!


I've also made a comparison of my TP-Link Archer C7 v2 wireless account point being run
a) using the built-in eth0 switch (four lan ports) to
b) using an additional external switch in front of it (TP-Link SG108E v5.0)

My access point was running fine in scenario a) running multiple wireless SSIDs on radio0 and 1 plus the switching capability. But I had a feeling my gaming performance could be slightly better - it was a feeling by stomach not backed by technical observation and measurement.

I can now tell scenario b) runs better if you'd like to have maximum performance. As I do have a lot of IOT components, e.g. Google Chromecast, Home and Amazon Alexas, the TP-Link SG108E does seem to reduce some multicast load from the TP-Link Archer C7 v2. (measured by using tcpdump on the Wifi AP).

I've also did this improvement to enable IGMPv3 snooping on my Archer Openwrt:

uci set network.[interface_name].igmp_snooping=1
uci set network.[interface_name].igmp_v3=1
uci set network.[interface_name].multicast_querier=0
uci commit network

Source of info:

1 Like

Thanks so much for sharing it! This image is suitable for the Archer C7 US version?

Uff I don't know the differences between EU and US models. So to be safe better do not use it, I've verified it working on my EU model but have no US model to test.

UPDATE: The US and EU images for the Archer C7 v2 are different. File compare gives the following output:


Here's a 19.07.4 build (with more packages, e.g. bash included) and EU/US variants for the C7v2 model. Link:

1 Like

Wow nice! Thanks! I'll give it a try when possible! Just out of curiosity, did you find out what is different between the two images?

1 Like

Yes, see my post above yours. The hex diff shows little difference, I guess it's because of the WiFi regulations that differ between countries?!