Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rwm32]

After more than 6 days' uptime, my ST546v6 rebooted itself on Sat.  I raised an eyebrow but didn't think too much of it, apart from checking the casing temperature -- warm but not hot.

Yesterday afternoon, it rebooted itself again... and again... and again.  Wouldn't stay up for more than 5 mins. Faulty unit, perhaps?  Well, no.  I took it offline and put on my TG585v7.  Same thing: rebooted itself every few minutes. (Not re-sync: full-blown reboot.)

I ran my ISP's automated fault checker (Madasafish). Initial checks were all clear, so per their instructions I disabled the h/w firewall in the router and launched the extended checks. After 3 hours, the thing reported that it couldn't complete the checks.

However, whether by coincidence or by something in the ISP's diagnostics, the fault appears to have cleared: the TG585v7 stayed connected all night. I've now switched back to the 546v6, which has now been up for an hour without incident.

So here's the question: What can cause a reboot (not just a re-sync) remotely?  How can the ADSL (WAN) line side trigger a warm restart / power cycle? In my (limited) understanding of these things, I thought that such events could only be triggered from the LAN unless remote access is enabled (which it isn't).

Further question: is this something I should be pursuing further with my ISP?

TIA for any explanations / comments / ideas!

rwm32

Current line stats:

Uptime: 0 days, 1:12:33
Modulation: G.992.1 Annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 7,168
Data Transferred (Sent/Received) [KB/KB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 21.5 / 36.0
SN Margin (Up/Down) [dB]: 20.0 / 9.5
Vendor ID (Local/Remote): TMMB / P
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 3 / 0
FEC Errors (Up/Down): 10 / 3,078
CRC Errors (Up/Down): 0 / 3
HEC Errors (Up/Down): 0 / 3

[roseway]

I don't really know the answer, but it's certainly not unknown for ADSL connection problems to cause routers to reboot, although I haven't come across a case like yours where it did so repeatedly. It may be caused by bugs in the router firmware, or it may be deliberate design whereby certain connection faults can only be cleared that way.

It sounds as though there was some sort of temporary problem with your line, which hopefully is now fixed.

[rwm32]

Well, there's some comfort to be had in knowing that line problems can cause a reboot...  and I clearly do have a line problem. First thing this a.m., before switching off the 585v7 (which sync's rather high because I can't tweak the target SNR: 6dB / 8000kbps), I noticed that -- very unusually -- there had been a handful of Loss of Frame errors and one Loss of Signal.

Normally, errors on my line at this SNR margin run at around 3 CRC / hour and < 2,000 FEC / hour, with no LoF or LoS. At the moment, not so good, though no LoF or LoS, perhaps because of the higher SNR margin that I set in the 546v6:

Uptime: 0 days, 3:17:41
Modulation: G.992.1 Annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 7,168
Data Transferred (Sent/Received) [KB/KB]: 0.00 / 1.00
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 21.5 / 36.0
SN Margin (Up/Down) [dB]: 20.0 / 9.5
Vendor ID (Local/Remote): TMMB / P
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 124 / 0
FEC Errors (Up/Down): 48 / 85,883
CRC Errors (Up/Down): 12 / 1,241
HEC Errors (Up/Down): 10 / 1,103

So quite clearly something ain't right out there.  While I've been typing this, the line re-sync'd (though the modem didn't reboot this time).  Have to wait and hope that it sorts itself out -- and start psyching myself up to do battle with customer services if it doesn't.  The serious downside is that these disconnections mean that using the VPN link into the office is a no-no. Luckily we haven't handed back the old 56k secure dial-up laptop yet...

[roseway]

Yes, you do seem to be clocking up errors at a fast rate. Before you call your ISP it's always worth checking these pages to try to nail down the cause of the problem.

[rwm32]

Thanks for that -- those pages are an excellent checklist.  As it happens, I did a full-blown overhaul of everything my side of the BT socket in March, so the only thing left to check was the (2-month-old, adslnation) microfilter; swapping it out made no difference.

However, full marks to Madasafish CS: they had already escalated a fault to BTw before I called them at lunchtime, on the basis of the automated diags that didn't complete last night. I'm impressed! I'm standing by to be even more impressed if BTw have already fixed it -- current line stats are much better, tho' the last reboot was less than an hour ago:

Uptime: 0 days, 0:47:59
Modulation: G.992.1 Annex A
Bandwidth (Up/Down) [kbps/kbps]: 448 / 7,040
Data Transferred (Sent/Received) [KB/KB]: 0.00 / 0.00
Output Power (Up/Down) [dBm]: 12.0 / 19.5
Line Attenuation (Up/Down) [dB]: 21.5 / 35.0
SN Margin (Up/Down) [dB]: 20.0 / 9.5
Vendor ID (Local/Remote): TMMB / P
Loss of Framing (Local/Remote): 0 / 0
Loss of Signal (Local/Remote): 0 / 0
Loss of Power (Local/Remote): 0 / 0
Loss of Link (Remote): 0
Error Seconds (Local/Remote): 0 / 0
FEC Errors (Up/Down): 0 / 431
CRC Errors (Up/Down): 0 / 0
HEC Errors (Up/Down): 0 / 0

I happened to catch a snapshot of the DMT SN margin just before one of the reboots, which says it all, I think...


[attachment deleted by admin]

[roseway]

Good for Madasafish, and I'll cross my fingers for you.