Home Network Community > All Threads > Archer C80 crashes constantly.
< All Threads

Archer C80 crashes constantly.

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.

Archer C80 crashes constantly.

This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.
Archer C80 crashes constantly.
Archer C80 crashes constantly.
2021-03-09 14:03:25 - last edited 2021-03-09 20:02:22
Model: Archer C80  
Hardware Version: V1
Firmware Version: 1.5.3 Build 210128 Rel.64503n(4555)

Hi,

 

I had Microtik Cap AC which did everything well except wireless part, slow speed and bad coverage. So after reading positive reviews, as my is 4G speed is about 60/40 Mbit link and I don't have any wifi6 devices, I brought four day's ago Archer C80.

 

Network is very simple, Huawei B535-232 4G router > LAN > C80 (192.168.10.0/24) > 2,4 & 5 Ghz & LAN, total less then 10 devices, 3 Lan and rest wifi users, no local NAS etc, so traffic is 100% towards to the Internet.

 

Today I noticed, that connection is jumping and the reason is here (pinging from LAN > C80):

64 bytes from 192.168.10.1: icmp_seq=169 ttl=63 time=1.297 ms
64 bytes from 192.168.10.1: icmp_seq=170 ttl=63 time=1.270 ms
64 bytes from 192.168.10.1: icmp_seq=171 ttl=63 time=1.376 ms
64 bytes from 192.168.10.1: icmp_seq=172 ttl=63 time=1.403 ms
64 bytes from 192.168.10.1: icmp_seq=173 ttl=63 time=1.419 ms
64 bytes from 192.168.10.1: icmp_seq=174 ttl=63 time=1.359 ms
64 bytes from 192.168.10.1: icmp_seq=175 ttl=63 time=1.295 ms
64 bytes from 192.168.10.1: icmp_seq=176 ttl=63 time=1.240 ms
64 bytes from 192.168.10.1: icmp_seq=177 ttl=63 time=1.332 ms
64 bytes from 192.168.10.1: icmp_seq=178 ttl=63 time=292.833 ms
64 bytes from 192.168.10.1: icmp_seq=179 ttl=63 time=909.688 ms
Request timeout for icmp_seq 180
Request timeout for icmp_seq 181
Request timeout for icmp_seq 182
Request timeout for icmp_seq 183
64 bytes from 192.168.10.1: icmp_seq=180 ttl=63 time=4117.857 ms
64 bytes from 192.168.10.1: icmp_seq=181 ttl=63 time=3147.291 ms
64 bytes from 192.168.10.1: icmp_seq=182 ttl=63 time=2142.475 ms
64 bytes from 192.168.10.1: icmp_seq=183 ttl=63 time=1141.740 ms
64 bytes from 192.168.10.1: icmp_seq=184 ttl=63 time=140.892 ms
64 bytes from 192.168.10.1: icmp_seq=185 ttl=63 time=685.739 ms
64 bytes from 192.168.10.1: icmp_seq=186 ttl=63 time=3224.804 ms
64 bytes from 192.168.10.1: icmp_seq=187 ttl=63 time=2225.081 ms
64 bytes from 192.168.10.1: icmp_seq=188 ttl=63 time=1223.377 ms
64 bytes from 192.168.10.1: icmp_seq=189 ttl=63 time=226.919 ms
64 bytes from 192.168.10.1: icmp_seq=190 ttl=63 time=64.227 ms
64 bytes from 192.168.10.1: icmp_seq=191 ttl=63 time=148.139 ms
64 bytes from 192.168.10.1: icmp_seq=192 ttl=63 time=95.403 ms
64 bytes from 192.168.10.1: icmp_seq=193 ttl=63 time=124.698 ms
64 bytes from 192.168.10.1: icmp_seq=194 ttl=63 time=1.329 ms
64 bytes from 192.168.10.1: icmp_seq=195 ttl=63 time=100.789 ms
64 bytes from 192.168.10.1: icmp_seq=196 ttl=63 time=252.941 ms
64 bytes from 192.168.10.1: icmp_seq=197 ttl=63 time=63.500 ms
64 bytes from 192.168.10.1: icmp_seq=198 ttl=63 time=154.785 ms
64 bytes from 192.168.10.1: icmp_seq=199 ttl=63 time=61.712 ms
64 bytes from 192.168.10.1: icmp_seq=200 ttl=63 time=1.349 ms
64 bytes from 192.168.10.1: icmp_seq=201 ttl=63 time=90.722 ms
64 bytes from 192.168.10.1: icmp_seq=202 ttl=63 time=127.353 ms
64 bytes from 192.168.10.1: icmp_seq=203 ttl=63 time=26.604 ms
64 bytes from 192.168.10.1: icmp_seq=204 ttl=63 time=189.534 ms
64 bytes from 192.168.10.1: icmp_seq=205 ttl=63 time=186.120 ms
64 bytes from 192.168.10.1: icmp_seq=206 ttl=63 time=135.052 ms
64 bytes from 192.168.10.1: icmp_seq=207 ttl=63 time=164.409 ms
64 bytes from 192.168.10.1: icmp_seq=208 ttl=63 time=91.712 ms
64 bytes from 192.168.10.1: icmp_seq=209 ttl=63 time=152.195 ms
64 bytes from 192.168.10.1: icmp_seq=210 ttl=63 time=115.573 ms
64 bytes from 192.168.10.1: icmp_seq=211 ttl=63 time=69.003 ms
64 bytes from 192.168.10.1: icmp_seq=212 ttl=63 time=82.933 ms
64 bytes from 192.168.10.1: icmp_seq=213 ttl=63 time=89.766 ms

etc

 

No load in LAN network, C80 is located in unheated storage room, LAN cable is fine (tested with Fluke cable tester), computer is fine, same happens with any connected LAN device, switching C80 ports doesn't help, all LAN ports are 1G full duplex.

 

As also others are noticing device crashing ( Archer C80 reboots automatically https://community.tp-link.com/en/home/forum/topic/235708 ), seems the product is faulty.


How to proceed?

 

Edit: According to the logs, the whole device crashes and reboots:

 

##########################################################################
#                    Archer C80  System Log
# Time = 2021-03-09 21:22:23 23452s
# H-Ver = Archer C80 1.0 : S-Ver = 1.5.3 Build 210128 Rel.64503n(4555)
# L = 192.168.10.1 : M = 255.255.255.0
# WAN = STATIC IP : W = 192.168.18.252 : M = 255.255.255.0 : G = 192.168.18.1
# Cnt = 10624, Free = 10571, Busy = 53
##########################################################################
  0days, 00:00:03, [lan]LAN: Attach mirror0 to stack.
  0days, 00:00:04, [lan]LAN: Set interface mirror0 ip=192.168.10.1 netmask 255.255.255.0.
  0days, 00:00:21, [wan]Attach interface eth0.
  0days, 00:00:21, [wan]STATIC-IP: eth0 set ip 192.168.18.252 mask 255.255.255.0 gateway 192.168.18.1.
  0days, 00:00:21, [wan]advanced ddns -wanChanged
  0days, 00:00:21, [wan]systool sntpc -sntpRequest
  0days, 00:00:21, [dnsproxy]Register Dns Detect
  0days, 00:00:21, [dnsproxy]Register primary = 0x8080808, secondary = 0x4040808
  0days, 00:00:21, [httpd]Http server start!
  0days, 00:00:25, [wan]Wan ethernet port plug on.
  0days, 00:00:25, [wan]STATIC-IP: eth0 set ip 192.168.18.252 mask 255.255.255.0 gateway 192.168.18.1.
  0days, 00:00:25, [wan]advanced ddns -wanChanged
  0days, 00:00:25, [wan]systool sntpc -sntpRequest
  0days, 00:00:25, [dnsproxy]Register Dns Detect
  0days, 00:00:25, [dnsproxy]Register primary = 0x8080808, secondary = 0x4040808

 

So this is serious issue, either the hardware is faulty or latest software causes it.

 

  0      
 
  0      
 
#1
Options
3 Reply
Re:Archer C80 crashes constantly.
2021-03-10 07:36:58

@ksuuk 

 

Thank you very much for all the detailed info about the crash issue you are experiencing with the C80. Can I have a picture of the power adapter that you are using powering the C80? We will escalate this case to the engineers, and ask them to analyze.

Nice to Meet You in Our TP-Link Community. Check Out the Latest Posts: Connect TP-Link Archer BE550 to Germany's DS-Lite (Dual Stack Lite) Internet via WAN Archer GE550 - BE9300 Tri-Band Wi-Fi 7 Gaming Router Archer BE800 New Firmware Added Support for EasyMesh in AP Mode, DoH&DoT, and 3-Band MLO Connection Archer AX90 New Firmware Added Support for EasyMesh and Ethernet Backhaul If you found a post or response helpful, please click Helpful (arrow pointing upward icon). If you are the author of a topic, remember to mark a helpful reply as the "Recommended Solution" (star icon) so that others can benefit from it.
  0  
  0  
#2
Options
Re:Archer C80 crashes constantly.
2021-03-10 20:02:12

@Kevin_Z 

 

Power adapter:

 

Power adapter -s output:

  0  
  0  
#3
Options
Re:Archer C80 crashes constantly.
2021-03-11 16:21:06 - last edited 2021-03-12 06:37:58

Since yesterday, I made some tests:

advanced > security > firewall > spi > no effect, back to enable
advanced > network > internet > nat boost > disable - possible reason?
advanced > wireless > advanced > airtime fairness > no effect, back to enable
advanced > wireless > advanced > short gi > disable - not sure yet
advanced > wireless > 2.4 ghz > 11n only > channel 6 - no effect, back to auto
advanced > wireless > 5 ghz > 11n/ac mixed > channel 40  - no effect, back to auto

 

Disabled, no need:
advanced > cwmp > inform > disable (used acs url http://127.0.0.1 acs user/passwd tplink)
advanced > iptv/vlan > igmp proxy > disable
advanced > network > ddns > tplink > no-ip > logout

and last night I had no issues, but then also were no active users. I'll keep testing more.

 

I'm not sure about nat boost, enabled it again, after some time however still at some point connection is problematic, latest example (I'm pinging from my wired device TP-Link and Huawei gateway -s) and my wired device is doing almost nothing, except ping, and router did not crash:

 

Apple > TP-Link

Mar 11 17:59:38 64 bytes from 192.168.10.1.1: icmp_seq=16764 ttl=64 time=0.657 ms
Mar 11 17:59:39 64 bytes from 192.168.10.1.1: icmp_seq=16765 ttl=64 time=0.694 ms
Mar 11 17:59:40 64 bytes from 192.168.10.1.1: icmp_seq=16766 ttl=64 time=1.811 ms
Mar 11 17:59:42 64 bytes from 192.168.10.1.1: icmp_seq=16767 ttl=64 time=440.787 ms
Mar 11 17:59:42 64 bytes from 192.168.10.1.1: icmp_seq=16768 ttl=64 time=0.734 ms
Mar 11 17:59:43 64 bytes from 192.168.10.1.1: icmp_seq=16769 ttl=64 time=0.723 ms
Mar 11 17:59:44 64 bytes from 192.168.10.1.1: icmp_seq=16770 ttl=64 time=0.612 ms
Mar 11 17:59:45 64 bytes from 192.168.10.1.1: icmp_seq=16771 ttl=64 time=0.717 ms
Mar 11 17:59:47 Request timeout for icmp_seq 16772
Mar 11 17:59:48 64 bytes from 192.168.10.1.1: icmp_seq=16772 ttl=64 time=1741.548 ms
Mar 11 17:59:49 64 bytes from 192.168.10.1.1: icmp_seq=16773 ttl=64 time=1772.725 ms
Mar 11 17:59:49 64 bytes from 192.168.10.1.1: icmp_seq=16774 ttl=64 time=1194.658 ms
Mar 11 17:59:49 64 bytes from 192.168.10.1.1: icmp_seq=16775 ttl=64 time=195.877 ms
Mar 11 17:59:50 64 bytes from 192.168.10.1.1: icmp_seq=16776 ttl=64 time=0.619 ms
Mar 11 17:59:51 64 bytes from 192.168.10.1.1: icmp_seq=16777 ttl=64 time=0.684 ms
Mar 11 17:59:52 64 bytes from 192.168.10.1.1: icmp_seq=16778 ttl=64 time=0.645 ms
Mar 11 17:59:53 64 bytes from 192.168.10.1.1: icmp_seq=16779 ttl=64 time=50.337 ms
Mar 11 17:59:54 64 bytes from 192.168.10.1.1: icmp_seq=16780 ttl=64 time=0.686 ms
Mar 11 17:59:55 64 bytes from 192.168.10.1.1: icmp_seq=16781 ttl=64 time=0.677 ms

 

Apple > TP-Link > Huawei

Mar 11 17:59:38 64 bytes from 192.168.18.1.1: icmp_seq=16761 ttl=63 time=1.259 ms
Mar 11 17:59:39 64 bytes from 192.168.18.1.1: icmp_seq=16762 ttl=63 time=1.303 ms
Mar 11 17:59:40 64 bytes from 192.168.18.1.1: icmp_seq=16763 ttl=63 time=2.302 ms
Mar 11 17:59:42 64 bytes from 192.168.18.1.1: icmp_seq=16764 ttl=63 time=441.281 ms
Mar 11 17:59:42 64 bytes from 192.168.18.1.1: icmp_seq=16765 ttl=63 time=1.339 ms
Mar 11 17:59:43 64 bytes from 192.168.18.1.1: icmp_seq=16766 ttl=63 time=1.219 ms
Mar 11 17:59:44 64 bytes from 192.168.18.1.1: icmp_seq=16767 ttl=63 time=1.101 ms
Mar 11 17:59:45 64 bytes from 192.168.18.1.1: icmp_seq=16768 ttl=63 time=1.197 ms
Mar 11 17:59:47 Request timeout for icmp_seq 16769
Mar 11 17:59:48 Request timeout for icmp_seq 16770
Mar 11 17:59:49 Request timeout for icmp_seq 16771
Mar 11 17:59:49 64 bytes from 192.168.18.1.1: icmp_seq=16769 ttl=63 time=3197.059 ms
Mar 11 17:59:49 64 bytes from 192.168.18.1.1: icmp_seq=16770 ttl=63 time=2196.859 ms
Mar 11 17:59:49 64 bytes from 192.168.18.1.1: icmp_seq=16771 ttl=63 time=1196.625 ms
Mar 11 17:59:49 64 bytes from 192.168.18.1.1: icmp_seq=16772 ttl=63 time=196.388 ms
Mar 11 17:59:50 64 bytes from 192.168.18.1.1: icmp_seq=16773 ttl=63 time=1.175 ms
Mar 11 17:59:51 64 bytes from 192.168.18.1.1: icmp_seq=16774 ttl=63 time=1.187 ms
Mar 11 17:59:52 64 bytes from 192.168.18.1.1: icmp_seq=16775 ttl=63 time=1.132 ms
Mar 11 17:59:53 64 bytes from 192.168.18.1.1: icmp_seq=16776 ttl=63 time=51.013 ms
Mar 11 17:59:54 64 bytes from 192.168.18.1.1: icmp_seq=16777 ttl=63 time=1.371 ms
Mar 11 17:59:55 64 bytes from 192.168.18.1.1: icmp_seq=16778 ttl=63 time=1.327 ms

 

Like I said, it's very difficult overload 1G full duplex port in real life, so what is going on with C80?

  0  
  0  
#4
Options

Information

Helpful: 0

Views: 1118

Replies: 3

Related Articles
Archer C80 V3?
573 0
Archer c80 problem
745 0
About OneMesh on Archer C80
1185 0
Archer C80 settings
1000 0
OneMesh and Archer C80
2566 0
Atualização Archer-C80
80 0
About Us
Press
Copyright © TP-Link Systems Inc. All rights reserved.