Superhub reboots between midnight and 1am

[Dragon_Nexus]

I've seen a few topics like this but none had any solutions.

From Sept 29th my superhub was rebooting (or otherwise losing connection and re-establishing it) between 1am and 2am. When the clocks went back, this window changed to somewhere between midnight and 1am. So either the superhub can't tell time, or something outside of the hub can't tell time if it happens within the same time frame every day.

Most of the time the internet's off for 5-10 minutes while it reboots. Sometimes it doesn't manage to reconnect until 4-6am. Rebooting the superhub does nothing.

I phoned the customer support today, the guy on the other end hadn't heard of this problem before. I don't blame him, it sounds outside of the normal issues one would have. My area apparently has a connection consistency issue which prevented him calling a technician out since there's already a logged problem. On his advice I restored the hub to factory default (holding down the reset button for 15 seconds) and spent an hour rebuilding my wireless network from scratch rather than importing a backup. At about 12:40, the internet went down again.

https://www.thinkbroadband.com/broadband/monitoring/quality/share/9561050659e21885a13326857f1eb27315617d9d-29-11-2021

Here's a graph from the 29th November so as not to confuse with the two reboots I did on the 1st Dec trying to fix the issue.

Downstream bonded channels

Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID

1	139000000	0.7	38	256 qam	1
2	147000000	1	38	256 qam	2
3	155000000	1.5	38	256 qam	3
4	163000000	2	38	256 qam	4
5	171000000	2.4	38	256 qam	5
6	179000000	2.7	38	256 qam	6
7	187000000	2.7	38	256 qam	7
8	195000000	2.5	38	256 qam	8
9	203000000	2.5	38	256 qam	9
10	211000000	2.4	38	256 qam	10
11	219000000	2.2	38	256 qam	11
12	227000000	2	38	256 qam	12
13	235000000	2	38	256 qam	13
14	243000000	2	38	256 qam	14
15	251000000	2.5	38	256 qam	15
16	259000000	3.2	38	256 qam	16
17	267000000	3.7	38	256 qam	17
18	275000000	4.1	38	256 qam	18
19	283000000	4.8	38	256 qam	19
20	291000000	5	38	256 qam	20
21	299000000	5.5	38	256 qam	21
22	307000000	6	40	256 qam	22
23	315000000	6.3	40	256 qam	23
24	323000000	6.3	40	256 qam	24

Downstream bonded channels

Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors

1	Locked	38.6	12	0
2	Locked	38.6	7	0
3	Locked	38.6	6	0
4	Locked	38.9	5	0
5	Locked	38.9	6	0
6	Locked	38.9	11	0
7	Locked	38.9	5	0
8	Locked	38.9	5	0
9	Locked	38.6	19	0
10	Locked	38.6	9	0
11	Locked	38.6	7	0
12	Locked	38.9	5	0
13	Locked	38.6	6	0
14	Locked	38.9	0	0
15	Locked	38.9	4	0
16	Locked	38.6	0	0
17	Locked	38.9	6	0
18	Locked	38.6	5	0
19	Locked	38.9	5	0
20	Locked	38.9	3	0
21	Locked	38.9	5	0
22	Locked	40.3	5	0
23	Locked	40.3	17	0
24	Locked	40.3	5	0

[Dragon_Nexus]

Upstream bonded channels

Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

1	60300000	51	5120	64 qam	1
2	53700000	51	5120	64 qam	2
3	46199980	51	5120	64 qam	3

Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1	ATDMA	0	0	1	0
2	ATDMA	0	0	0	0
3	ATDMA	0	0	0	0

Network Log

Time Priority Description

02/12/2021 00:52:34	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/12/2021 00:46:13	Warning!	TCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/12/2021 00:46:13	Warning!	Initializing Channel Timeout Expires - Time the CM can perform initial ranging on all upstream channels in the TCS has expired;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/12/2021 00:29:38	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/12/2021 00:13:14	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 23:29:43	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 22:54:52	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 22:43:13	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 22:42:27	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 22:40:14	Warning!	LAN login FAILED : Incorrect Username / Password / ConnectionType;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:21:33	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:18:11	Warning!	TCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:18:11	Warning!	Initializing Channel Timeout Expires - Time the CM can perform initial ranging on all upstream channels in the TCS has expired;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:16:3	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:15:35	critical	REG RSP not received;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:15:35	Error	T6 Timeout and retries exceeded;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:15:35	critical	Registration RSP rejected unspecified reason;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 17:15:35	critical	Registration RSP rejected message syntax error;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 16:52:21	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/12/2021 16:48:5	Warning!	TCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

[lotharmat]

Your upstream has a problem - there should be 4 channels - the power is also at the top of acceptable.

If there are no issues listed on 0800 561 0061, you need to call it in as a fault on 150 (0345 454 1111)

Or wait for a VM forum rep - could take a day or so!

[Dragon_Nexus]

Would that cause the hub to reboot on a night? Or is that just a general issue? What can an incorrect upstream do?

[Tudor]

Looking at your log, the hub has not rebooted, it’s just lost its connection to the VM CMTS. This is almost certainly due to the lack of 4 upstream channels and the very high power level on the existing ones. Do this:

Check with Area faults on  0800 561 0061 or if you have a VM landline 150

If no faults found:

Call Customer Services on 0345 454 1111/150 if you have a VM landline or wait a day or two for a VM staff member to get to your post.

[Dragon_Nexus]

As stated in my initial post, the guy I spoke to was unable to send an engineer out since there's a consistency issue logged in the local area. He couldn't go through any trouble shooting options because of that.

Area faults on the 0800 number said everything was fine.

Could the upstream really cause a disconnect at the same time frame every day? Like, within the same hour?

[jbrennand]

Switch the Hub off for 5' and then start it up. If there are still only 3 Up channels then therein lays your issue.

You need a Tech visit to rectify that, If the script reading offshore droids cannot see that, just wait a day or two on here for a VM person to respond and take a look

[Dragon_Nexus]

Turned it off for 5 minutes and the upstream looks like this.

Upstream bonded channels

Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

1	60300000	51	5120	64 qam	1
2	46200000	51	5120	64 qam	3
3	53700000	51	5120	64 qam	2

Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1	ATDMA	0	0	0	0
2	ATDMA	0	0	0	0
3	ATDMA	0	0	0	0

So no real change.

Though I think you're being a bit unfair to the tech support guy. He knew it needed a technician, but couldn't get one for me because there's an existing problem in the area.

It's not a great look calling them droids reading from a script if you don't actually read the things I'm posting, because I said as much at least once, possibly twice.

I'll carry on waiting to see if a VM support person comes along. I appreciate the help thus far, it's nice to know what the potential cause might be. Still find it odd that this doesn't just cause random losses rather than losses in a specific time frame.

[jbrennand]

What is a "consistency issue"? That's a new one on me - or the CS person was being very creative with the English language. I will flag for a real VM person to come here and comment

[David_Bn]

Thanks for your posts @Dragon_Nexus,

I've been able to run a flow on your equipment and can see we will need an engineer.

Check out the purple envelope in the top right hand corner for a private message from me

Kindest regards,

David_Bn