State of Archer C7 v2 in mid-2020

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
reboot

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:

image

Here's a 19.07.4 build (with more packages, e.g. bash included) and EU/US variants for the C7v2 model. Link: https://drive.google.com/file/d/16ck-pmNGRlSRCwVT2QKxbBW4hsbtD0TP/view?usp=sharing

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?!

I am so glad to have come upon this post. @Catfriend1 I have loaded your image and I am still seeing a drop on 2.4ghz. Any help that anyone can provide is greatly appreciated. I am going crazy trying to figure this thing out. Devices are definitely close enough. Bandwidth is great when it is connected. My printer and doorbell keep disconnecting. It is causing the doorbell to drain the battery very quickly. I couldn't figure exactly how to add in the watchdog script as I am very new to this. Also should I be turning off the WAN6 interface as I am seeing contrasting information in some of the forums?

Device is Archer C7v2 Powered by LuCI openwrt-19.07 branch (git-20.319.48994-50b7ab5) / OpenWrt 19.07.4 r11208-ce6496d796

I keep seeing the below in the log about every 2-3 minutes but I am not sure what it means.

Thu Nov 19 17:37:47 2020 daemon.info dnsmasq-dhcp[5095]: DHCPOFFER(br-lan) 192.168.11.191 fc:6b:f0:c4:1a:d8
Thu Nov 19 17:37:47 2020 daemon.info dnsmasq-dhcp[5095]: DHCPREQUEST(br-lan) 192.168.11.191 fc:6b:f0:c4:1a:d8
Thu Nov 19 17:37:47 2020 daemon.info dnsmasq-dhcp[5095]: DHCPACK(br-lan) 192.168.11.191 fc:6b:f0:c4:1a:d8 DEFAULT

That is the ip address for my video doorbell. Heimvision HMB1.

@Catfriend1 I'm a little confused by your Target Profile: TP-Link Archer C7 v5
I'd have expected that to be v2 by the title of the tread...
Is that intentional? Do you get better results running the build for v5 on v2?
Or do you have both v2 and v5 and this is just the description for the wrong device?

I've done two builds. one for v2 and one for v5.

1 Like

Did anyone try 19.07.5 official build yet? I'd like to know if there's again the ct driver in it and it's stability has increased because I don't know if ct driver got patches between the last and this release.

I installed the new version on my Archer C7 v2.
Default drivers are:

The stability seems to be not better than with .4

Uwe

1 Like

Seems to be the same version numbers that I have in 19.07.4. I believe I had changed things for ct-smallbuffers as an experiment, version numbers seem the same. Bummer, I was hoping for a bump in the new stable. I know there was a bump in master some weeks back, guess we have to run a snapshot for that...

1 Like

Hi there, I was following along with you since topic opened on September. I had to struggle a little bit with the hardware, but know I got it working properly with the old driver set provided by @Catfriend1 firmware build - thanks a lot for compiling the custom image. Nevertheless I can stand, that the newly integrated firmware is still unstable and will cause my network performance to drain from 20MB/s to 1MB/s. (checked on V2 and V5 router)

In the end I am currently at around 20MB/s on a MacBook and around 30-35MB/s on my Fedora workstation. Peaks will go up to 50-75MB/s. The only worse thing I noticed, that voip will make troubles. (not topic of this thread will do another one later on)

regards
Carsten

1 Like

Follow up to my post above with 19.07.5 build including mesh, batman-adv, bash and non-ct ath10k driver.

1 Like

@Catfriend1 So, to try this out, I'd just download the file from your Google Drive and upload the firmware to my current 19.07.05 install of OpenWRT?

1 Like

Yes, you can.

1 Like

Hello,

I have installed 19.07.05 all is working fine except that I cannot install wireguard from the GUI:-

Collected errors:

  • satisfy_dependencies_for: Cannot satisfy the following dependencies for wireguard:
  • kernel (= 4.14.209-1-b84a5a29b1d5ae1dc33ccf9ba292ca1d)
  • opkg_install_cmd: Cannot install package wireguard.

Any idea how to fix installtion of wireguard plz?

@lycanwrath Do you use my build or official ones? I did not find any way yet to install officially built kmod's into my build. I first also thought it should be somehow possible because I've built from the official release commit so expecting the kernel is the same.

I am using your 19.07.5 build, I flashed the file openwrt-ath79-generic-tplink_archer-c7-v2-squashfs-factory-eu.bin

From what I am reading, the issue happens because the kernel/firmware hash changes as soon as it is modified and recompiled, making the package install/update process fail.

The only way to install the package is to include it with the firmware or have it created as a module at time of commit.

"
snapshots are built daily, and that sets time limits to installing new packages with opkg. Due to kernel version checksums, you can only install “kmod” kernel modules and other kernel version dependent modules from the exactly same snapshot build. So, a few hours after flashing the firmware you may not be able to install new modules with opkg any more (as the next snapshot has been built into the download repo and has different checksums).
"

Source:

1 Like

I think this article might be a solution to the issue of opkg install:-

1 Like

Hmm... thanks. but i think as we swapped included kmods it won't work. We need the non ct drivers.