State of Archer C7 v2 in mid-2020

Installing and Using OpenWrt
30

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.

31

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

32

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

1 Like
33

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.

34

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

Notes_201213_225620_f10
Notes_201213_225620_f10826×193 24.5 KB

The stability seems to be not better than with .4

Uwe

1 Like
35

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
36

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
37

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

1 Like
38

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

Yes, you can.

1 Like
40

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?

41

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

42

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
43

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

1 Like
44

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

45

Using ath10k non-ct drivers OpenWrt 19.07.5 here. I've got rock solid stability most of the time and throughput is a dream with non-ct drivers. After about 30 ... 40 days, 2.4 GHz WiFi devices can no longer discover or log into the Wifi SSID. I've investigated the logs closely moreoften when this happened and installed syslog-ng to be able to compare a working state with a non-working state. I've noticed so far, when the problem begins the line:

netifd: Network device 'wlan1' link is up

for 2.4 GHz Wifi is missing. Issuing "wifi up" via SSH to the device brings it back to life. What I don't understand: I use cron to modify the wireless conf to turn off radios at night and the script also ends with "wifi up". Today, the wifi up after the night failed (above log line missing) and manually issuing "wifi up" solved the problem.

What problem does the driver/hostapd/netifd or whatever have here? It's coming sporadic and can be solved with "wifi up" or "reboot" (I'd like to avoid rebooting). Anywhere to file a bug report you'd wish I'd do?

1 Like
46

That issue is slowly getting out of hand.
In the past few weeks I also noticed the same behaviour on the 5 GHz network for a few times.
Only a reboot of the router could fix it.

Is there any command I can run so that ONLY the wifi part gets restarted?
I would then set this as a cron job to run everynight....
This hopefully works around the issue. But there is clearly something broken in the firmware.

47

@TheHellSite

wifi

or

wifi up

helped me when the wifi stopped working last time after 32d uptime without issues. I thought I needed to reboot sooner or later after that, but until today it's
still running stable. uptime is now 45d.

48

Continued in: https://forum.openwrt.org/t/state-of-tp-link-archer-c7v2-v5-in-2021
Please close if appropriate.

1 Like