TP-Link Archer C7: intermittent cable network connectivity

Installing and Using OpenWrt
1

Hi

I just bought a used TP-Link Archer C7 AC1750 (EU) Ver. 5.0 and flashed the newest OpenWrt 23.05.5 factory firmware image (openwrt-23.05.5-ath79-generic-tplink_archer-c7-v5-squashfs-factory.bin) onto it using (I believe) the WebUI of the original OEM firmware. Everything went smoothly and is working fine, including 2.4 and 5.0 GHz WiFi, except that network connectivity is vanishing in quite regular intervals. See these ping drops:

root@OpenWrt-ArcherC7:~# ping google.com 
ping: bad address 'google.com'
root@OpenWrt-ArcherC7:~# ping 142.250.203.110
PING 142.250.203.110 (142.250.203.110): 56 data bytes
64 bytes from 142.250.203.110: seq=0 ttl=116 time=3.266 ms
64 bytes from 142.250.203.110: seq=1 ttl=116 time=4.508 ms
64 bytes from 142.250.203.110: seq=2 ttl=116 time=5.258 ms
64 bytes from 142.250.203.110: seq=3 ttl=116 time=6.090 ms
64 bytes from 142.250.203.110: seq=4 ttl=116 time=6.861 ms
64 bytes from 142.250.203.110: seq=5 ttl=116 time=6.746 ms
64 bytes from 142.250.203.110: seq=6 ttl=116 time=6.324 ms

64 bytes from 142.250.203.110: seq=28 ttl=116 time=1188.829 ms
64 bytes from 142.250.203.110: seq=29 ttl=116 time=189.433 ms
64 bytes from 142.250.203.110: seq=27 ttl=116 time=2190.366 ms
64 bytes from 142.250.203.110: seq=30 ttl=116 time=6.812 ms
64 bytes from 142.250.203.110: seq=31 ttl=116 time=6.601 ms
64 bytes from 142.250.203.110: seq=32 ttl=116 time=6.356 ms
64 bytes from 142.250.203.110: seq=33 ttl=116 time=6.161 ms
64 bytes from 142.250.203.110: seq=34 ttl=116 time=5.984 ms
64 bytes from 142.250.203.110: seq=35 ttl=116 time=6.330 ms
64 bytes from 142.250.203.110: seq=36 ttl=116 time=6.175 ms
64 bytes from 142.250.203.110: seq=37 ttl=116 time=5.949 ms

64 bytes from 142.250.203.110: seq=59 ttl=116 time=1543.746 ms
64 bytes from 142.250.203.110: seq=60 ttl=116 time=543.608 ms
64 bytes from 142.250.203.110: seq=61 ttl=116 time=3.366 ms
64 bytes from 142.250.203.110: seq=62 ttl=116 time=5.670 ms
^C
--- 142.250.203.110 ping statistics ---
63 packets transmitted, 22 packets received, 65% packet loss
round-trip min/avg/max = 3.266/261.565/2190.366 ms

Right now everything is connected using just the cable, so WiFi is not a factor here. The pings above are sent from the router, and it's the same if they're being sent through the router from a DHCP client machine. What am I doing wrong?

I am unable to replicate this problem when connecting to the internet directly through my gateway modem, without the OpenWrt router box in the way.

Thanks!

2

If you connect a PC and ping you should be able to observe similat upstream glitches?

3

Yes of course.

Everything works fine though if I skip my OpenWrt box and connect to my ISP's modem directly (cable or wifi, doesn't matter). So, my desired setup is:

+-------------+            +---------+                 +----+
| ISP's modem | <--Cable-- | OpenWrt | <--Cable/WiFi-- | PC |
+-------------+            +---------+                 +----+

it just doesn't work because of those glitches (even if connected just by the cable, no WiFi). This works just fine:

+-------------+            +----+
| ISP's modem | <--Cable-- | PC |
+-------------+            +----+
4

Try using another physical cable -- ideally a short one that is known good.

5

Hm, I do not have a cable tester here but I tried 5 different cables lying around, all rather short (up to 1 meter or so), and it's all the same. I even tried different LAN Ethernet sockets of the ISP modem. What else could it be?...

6
Inspect your cables -- are they 4 or 8 conductor?

Have you checked for any bent pins or debris in the connectors on both devices?

[EDIT -- I got my own cables crossed in my brain... lol. Probably not a cable issue... I think I was confusing this with a different thread where cables may be an issue]

Also... what is the address on the wan of the OpenWrt router? Just show us the first two octets (in bold: aaa.bbb.ccc.ddd):

ifstatus wan | grep address
7

You can try reducing negotiated speed offer to 100Mbps in hope it stops resetting:

ethtool -s lan1 advertise 0x9 # 0x29 would also add gigabit
ethtool -r lan1 # renegotiate

If it works you can add commands with full ethtool path to /etc/rc.local