VR2100 reboots every few hours
I have a VR2100 that reboots every few hours connected to PlusNet in the UK on unlimited fibre to cabinet. (VDSL2)
DSL using VDSL2, SNR 6.1 up 2.8 down, Atten 1.2db up 10.8 down.
When it is up, connection is reliable.
When it reboots all lights go and start flashing after a few minutes the DSL connection is re-established.
Case temperature is relatively cool, room temp about 18C, case probably 25C.
Nothing in the logs since they are wiped on every reboot. I will setup a syslogd server to capture logs remotely, just in case.
It is a few months old.
Previous DSL modem was the OpenReach VDSL Modem which never disconnected or rebooted except during power cuts (1 per year).
I have read the other threads with the same problem on the same modem and firmware.
Is there new firmware (even beta) available that will stop it rebooting.
Would be happy to share logs, if you would help get a fix sooner.
If there isnt any fix, I can switch to a spare (old DLink), which the VR2100 was bought to replace.
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Have received a new debug firmware image (datestamped yesterday 2021-01-06 ) from TP-Link support (thank you), with a fixed DSL Driver. This has now been stable for 24h with no reboots. Also, the error packets seen on the DSL layer have dropped to zero and IP clients are no longer seeing pauses in traffic. The maximum bandwidth seen is marginally greater than the predicted line speed for both up and down.
Uptime so far 22h8m, which is at least 6x longer than with the default firmware on my DSL connection.
So far this new firmware seems to have fixed the problems with the DSL part of this router.
If I don't report back, and you are reading this then assume this is fixed and look for new published firmware.
When configured as a router, I did not have any crashes using the previous debug firmware. None since my last post.
There is firmware (Archer VR2100(EU)_V1_201122 published 2020-12-24) however this crashed for me as a router and as a modem and did not fix the issue reported here.
BTW, TP-Link support is excellent. I wasn't expecting it to be so good for a consumer product.
- Copy Link
- Report Inappropriate Content
Hello all, sorry to hear that you experience an auto-reboot on the VR2100.
If the auto-reboot issue, unfortunately, persists on the latest firmware, please kindly check if the latest beta firmware we provided in the below thread:
(Updated on 2021-06-22)
https://community.tp-link.com/en/home/forum/topic/262804
This is the guide to update this beta firmware manually:
https://www.tp-link.com/support/faq/1756/
I hope this helps, good day.
- Copy Link
- Report Inappropriate Content
The debug logs send over UDP to a syslogd deamon running on a machine connected via wifi do not report any abnormal messages when the router crashes.
The only unusual log message about 90s before the last message was seen is a DHCP renew request that clashed with a IP reserved by a different MAC (I have obfuscated the ids, since this is public.)
ec 18 10:51:43 PPP <Debug>: rcvd [LCP EchoRep id=0x41 magic=0x6fYYYYb1]
Dec 18 10:52:01 PPP <Debug>: rcvd [LCP EchoReq id=0x42 magic=0x6fYYYYb1]
Dec 18 10:52:01 PPP <Debug>: sent [LCP EchoRep id=0x42 magic=0xaZZZZ8ef]
Dec 18 10:52:05 DHCPD <Debug>: Recv REQUEST from BB:BB:BB:BB:BB:BB
Dec 18 10:52:05 DHCPD <Notice>: REQUEST ip c0a8016f already reserved by AA:AA:AA:AA:AA:AA
Dec 18 10:52:05 DHCPD <Notice>: Send NAK
Dec 18 10:52:06 DHCPD <Info>: Recv DISCOVER from BB:BB:BB:BB:BB:BB
Dec 18 10:52:06 DHCPD <Notice>: Send OFFER with ip 192.168.X.114
Dec 18 10:52:07 DHCPD <Debug>: Recv REQUEST from BB:BB:BB:BB:BB:BB
Dec 18 10:52:07 DHCPD <Notice>: Send ACK to 192.168.X.114
Dec 18 10:52:13 PPP <Debug>: sent [LCP EchoReq id=0x42 magic=0xaZZZZ8ef]
Dec 18 10:52:13 PPP <Debug>: rcvd [LCP EchoRep id=0x42 magic=0x6fYYYYb1]
Dec 18 10:52:31 PPP <Debug>: rcvd [LCP EchoReq id=0x43 magic=0x6fYYYYb1]
Dec 18 10:52:31 PPP <Debug>: sent [LCP EchoRep id=0x43 magic=0xaZZZZ8ef]
Dec 18 10:52:43 PPP <Debug>: sent [LCP EchoReq id=0x43 magic=0xaZZZZ8ef]
Dec 18 10:52:43 PPP <Debug>: rcvd [LCP EchoRep id=0x43 magic=0x6fYYYYb1]
Dec 18 10:53:01 PPP <Debug>: rcvd [LCP EchoReq id=0x44 magic=0x6fYYYYb1]
Dec 18 10:53:01 PPP <Debug>: sent [LCP EchoRep id=0x44 magic=0xaZZZZ8ef]
Dec 18 10:53:13 PPP <Debug>: sent [LCP EchoReq id=0x44 magic=0xaZZZZ8ef]
Dec 18 10:53:13 PPP <Debug>: rcvd [LCP EchoRep id=0x44 magic=0x6fYYYYb1]
Dec 18 10:53:31 PPP <Debug>: rcvd [LCP EchoReq id=0x45 magic=0x6fYYYYb1]
Dec 18 10:53:31 PPP <Debug>: sent [LCP EchoRep id=0x45 magic=0xaZZZZ8ef]
Last message seen ^^^
Might have got more if it wasn't over wifi.
- Copy Link
- Report Inappropriate Content
Thank you very much for all the details about the modem auto-reboot issue, I will send you a beta firmware to confirm if it will help with the reboot, please check the PM, thanks.
- Copy Link
- Report Inappropriate Content
Thanks, will do.
Crashed again a moment ago, with a DHCP operation showing about 90s before.
This time a perfectly normal DHCP DISCOVER, OFFER, REQUEST, ACK (11 clients at the time)
perhaps segv or memory leak in the dhcp server ?
- Copy Link
- Report Inappropriate Content
Beta Image installed, verified logging to USB.
Stable with no crashes for the past 24h, same number of connected clients however lower traffic levels.
Establishing wifi connections seems more stable with fewer DHCP retries from clients on initial connects, previously some clients would request multiple times and miss the offers. Other clients would drop the wifi connection randomly and only reconnect if within 1m of the router.
VDSL2 connection has not dropped for 24h. SNR and line attenuation approximately the same as before.
No unusual patterns in any of the logs, other than one or two lines about writing to flash (highlighted red in xterm cat output)
- Copy Link
- Report Inappropriate Content
Thank you very much for your valued reply, please keep monitoring the router performance, then get back to us with the debug log.
BTW, we will email you, please send us the debug log via email. Good day.
- Copy Link
- Report Inappropriate Content
Still Stable (48h uptime), no crashes, VDSL2 connection has not dropped, all levels still the same.
Over the 48 period I see 194 error packets upstream and 1 error packet downstream (ie almost none)
WiFi Stable no clients reporting drops.
syslogd captured logs reported LAN1 down for 13s at 3am. No other log messages to indicate trouble there, only 1 device on wired ethernet.
Dec 21 03:22:40 System <Notice>: LAN1 link down
Dec 21 03:22:53 System <Notice>: LAN1 link up 100 mbps
UI reports memory at 64%, slightly up from when it was booted.
CPU at 1%.
Will retrieve the contents of the USB Drive over the network and send to you via email as requests.
- Copy Link
- Report Inappropriate Content
Crashed at 15:30.
No activity in syslog logs close to the crash other than the PPP LCP echo messages at debug level every 30s.
Sharing debug logs over email.
- Copy Link
- Report Inappropriate Content
Crashed 18:22
Nothing in the syslogd logs to indicate trouble.
Sharing the debug log over email.
Been stable since then 16h.
- Copy Link
- Report Inappropriate Content
Support suggested I switch from setting up the device as a VDLS modem to a router using the original BT OpenReach supplied VDSL modem.
No crashes seen for 64h indicating the problem lies in the VDSL modem section of the router.
- Copy Link
- Report Inappropriate Content
Good to know there is a workaround, please keep using it as a wireless router, the dev team will figure this out.
- Copy Link
- Report Inappropriate Content
Information
Helpful: 0
Views: 3795
Replies: 25
Voters 0
No one has voted for it yet.