Superhub : Superhub or router at fault?

[carbon60]

I keep having periodic problems with the internet dropping. If I reset the Superhub or the Netgear FVS338 then the internet is restored so I don't know which is at fault. I do get messages in the Superhub Event Log around the time that it happens.

I've pasted my Superhub Event Log and Signal levels in the hope that one of you might be able to see what is wrong.

Event Log with MAC Addresses removed:

Fri Jul 06 12:03:53 2012 Critical (3) DHCP FAILED - Requested Info not supported.;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 12:03:30 2012 Critical (3) DHCP FAILED - Discover sent, no offer received;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;

Fri Jul 06 12:02:17 2012 Critical (3) No Ranging Response received - T3 time-out;CM-MAC=;CMTS-MAC=;CM-QOS=1.0;CM-VER=3.0;

Fri Jul 06 12:01:13 2012 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 12:00:41 2012 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 11:35:51 2012 Critical (3) SYNC Timing Synchronization failure - Failed to acquire FEC framing;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 11:35:51 2012 Warning (5) Lost MDD Timeout;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 11:35:51 2012 Warning (5) MDD message timeout;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 07:40:39 2012 Critical (3) SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Fri Jul 06 07:16:17 2012 Critical (3) SYNC Timing Synchronization failure - Failed to receive MAC SYNC frame within time-out period;CM-MAC=;CMTS-MAC=;CM-QOS=1.1;CM-VER=3.0;

Connection

Startup Procedure
Procedure Status Comment
Acquire Downstream Channel 307000000 Hz Locked
Connectivity State OK Operational
Boot State OK Operational
Configuration File OK
Security Enabled BPI+

Downstream Channels
Lock Status Modulation Channel ID Max Raw Bit Rate Frequency Power SNR Docsis/EuroDocsis locked
Locked QAM256 159 55616000 Kbits/sec 307000000 Hz 0.4 dBmV 39.4 dB Hybrid
Locked QAM256 157 55616000 Kbits/sec 291000000 Hz 1.0 dBmV 39.4 dB Hybrid
Locked QAM256 158 55616000 Kbits/sec 299000000 Hz 0.7 dBmV 39.4 dB Hybrid
Locked QAM256 160 55616000 Kbits/sec 315000000 Hz 0.2 dBmV 39.4 dB Hybrid
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV 0.0 dB Unknown

Upstream Channels
Lock Status Modulation Channel ID Max Raw Bit Rate Frequency Power
Locked ATDMA 25 20480 Kbits/sec 35800000 Hz 45.5 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV

Primary Downstream Service Flow
Downstream(0)
SFID 58293
Max Traffic Rate 66000000 bps
Max Traffic Burst 10000 bytes
Mix Traffic Rate 0 bps

Primary Upstream Service Flow
Upstream(0)
SFID 58292
Max Traffic Rate 3072000 bps
Max Traffic Burst 8160 bytes
Mix Traffic Rate 0 bps
Max Concatenated Burst 8160 bytes
Scheduling Type Best Effort

[LLM]

Hi
Can I suggest you have a look at this thread:

http://www.cableforum.co.uk/board/12...hire-area.html

Please read the reply I posted yesterday. Your router log is almost identical to a large number of the entries on my SuperHub routers (plural) over the last three months.

As a former head of IT for a large organisation which depended on 100% uptime for its internet connectivity, I know there are many possible reasons for client interruptions.

In my own personal set-up, I have used Virigin Superhubs in both wireless router and in modem-only modes with other proven router products and with a variety of client software platforms. None produced any greater stability.

I am convinced that the majority of the interrupts I have experienced during 2012 are due almost entirely to Virgin server issues and almost certainly as a consequence of their recent upgrade programme. The thread referred to above explains more background.

I am now observing the results of the latest minor tweaks to my own home config carried out by Virgin this week. I have had no drop-outs for 36hrs (a short-term record), but ain't holding my breath. Virgin is going to have to admit it has a server-side issue and address it.
Best
LLM

[General Maximus]

I love threads like this because before I even read them 99.9% of the time I can just say it is the shub's fault In this case though as much as it pains me to say it, the shub isn't at fault, either as a router or modem. Your power levels are good but for some reason you are having problems establishing a connection with the cmts. It is defo going to be an area fault and you need to ring tech support. They'll send an engineer out thinking the problem is your end but he'll be able to escalate it to networks and get it looked at.

[carbon60]

Thanks for your reply. We originally started having problems when we added Sky Sports a few months ago. Within a few minutes the internet went down, we had a SA 2100 at the time - the modem just couldn't lock onto the overlay network. VM sent out a technician who simply changed the modem for a Superhub much to my dismay.

It seems odd that rebooting either the router or Superhub fixes the problem. It's almost as if the DHCP renewal doesn't get passed correctly to the router and they lose communication.

---------- Post added at 23:44 ---------- Previous post was at 23:36 ----------

Originally Posted by General Maximus

I love threads like this because before I even read them 99.9% of the time I can just say it is the shub's fault In this case though as much as it pains me to say it, the shub isn't at fault, either as a router or modem. Your power levels are good but for some reason you are having problems establishing a connection with the cmts. It is defo going to be an area fault and you need to ring tech support. They'll send an engineer out thinking the problem is your end but he'll be able to escalate it to networks and get it looked at.

Thanks. I've had similar thoughts. Originally I thought about Superhub's reputation so instantly blamed it. I had issues with my brother's PS3 causing the connection to drop but later I found out it was because I updated my router's firmware to one which had a bug which crashed it. I downgraded it and it stopped doing it. I had another issue where my father couldn't send email via smtp.blueyonder.co.uk, again I blamed the Superhub when in fact it's a known problem with that server. So for everything I blamed the Superhub for it has been innocent :-)

However in this case I don't know where to turn. I managed to get 50+ days uptime recently until my father cycled the power to do some work in the bathroom so it can be stable but sometimes this problem with the connection dropping happens.

My question is, if the issue is caused by a communication problem with the cmts then why would power cycling the router fix it?

[jb66]

Originally Posted by General Maximus

I love threads like this because before I even read them 99.9% of the time I can just say it is the shub's fault In this case though as much as it pains me to say it, the shub isn't at fault, either as a router or modem. Your power levels are good but for some reason you are having problems establishing a connection with the cmts. It is defo going to be an area fault and you need to ring tech support. They'll send an engineer out thinking the problem is your end but he'll be able to escalate it to networks and get it looked at.

Lol

[jower]

I know there are many possible reasons for client interruptions.

[Sephiroth]

Mon General is spot on. BTW the sh event logs you posted could be reporting what happens during the reset process, in which case the messages don't count! The events at 07:40 and 11:35 could be in-flight events which would reinforce Mon General's suggestion.

You can ignore the DHCP message at the top of the event log - some configurations accept the parameters, some don't but they function normally on the configuration defaults.

[carbon60]

Originally Posted by Sephiroth

Mon General is spot on. BTW the sh event logs you posted could be reporting what happens during the reset process, in which case the messages don't count! The events at 07:40 and 11:35 could be in-flight events which would reinforce Mon General's suggestion.

You can ignore the DHCP message at the top of the event log - some configurations accept the parameters, some don't but they function normally on the configuration defaults.

The messages at the top are around the time the internet went down. Could you give me some further insight to what the DHCP messages actually mean?

[General Maximus]

Originally Posted by carbon60

The messages at the top are around the time the internet went down. Could you give me some further insight to what the DHCP messages actually mean?

When you connect to the internet it isnt like plugging your hose pipe into the tap and you get water. The modem does several things as it establishes it's connection to the cmts such as determining the correct power level it needs etc. Once the physical connection has been established the next thing it needs (along with any device which connects to a network, whether it be internet or lan) is an ip address. Your ip address is the address VM gives your router (and thus all devices in your house) and has be to globally unique. As an example, when you go to youtube.com you will fire off a request to the google dns servers saying "hey, can I have the ip address for youtube.com" and it will reply saying it is 192.168.2.4 (or whatever it is) but that message has to have some way of getting back to you. So VM give youj an ip address which it knows is yours so data across the internet can get back to your router and your router is responsible for ensuring it gets back to the right device on your lan (another story which i wont get in to).

Soooo, dhcp (dynamic host configuration protocol) is basically a way of automatically assigning ip addresses (like giving out street numbers) rather than somebody having to do it all manually. If you setup your own network with 10 devices you could manually configure their ip addresses but for VM they will give the cmts a pool of ip addresses (like 82.174.1.1 - 82.174.255.254) and it will hand out whatever addresses are not in use at the time when you modem trys to connect. DHCP messages are the modem talking to the cmts saying "hey I need an ip address" and the cmts saying "sure, is this one ok".

[Milambar]

I think he actually wanted to know wat the "Requested info not supported" part of the message meant.

I wonder if the OP has gotten it lodged in is head that the "Requested info not supported" is the cause of his fault. If so, I can say its probably not the case, because my superhub logs are also filled with those messages, and I have a working and stable connection.

I think from the point of view of fault diagnostics, those messages can be disregarded.

[carbon60]

Originally Posted by Milambar

I think he actually wanted to know wat the "Requested info not supported" part of the message meant.

I wonder if the OP has gotten it lodged in is head that the "Requested info not supported" is the cause of his fault. If so, I can say its probably not the case, because my superhub logs are also filled with those messages, and I have a working and stable connection.

I think from the point of view of fault diagnostics, those messages can be disregarded.

Yes, it was those parts of the messages I was interested in. I'm aware of how DHCP operates I was more interested in how the Superhub passes this address to my router. When this has happened in the past I've been unable to get to http://192.168.100.1/ - resetting the Superhub or router fixes this problem. I'm interested in how the two devices lose communication.

[Eeeps]

Originally Posted by carbon60

Yes, it was those parts of the messages I was interested in. I'm aware of how DHCP operates I was more interested in how the Superhub passes this address to my router. When this has happened in the past I've been unable to get to http://192.168.100.1/ - resetting the Superhub or router fixes this problem. I'm interested in how the two devices lose communication.

If you are operating the SHub in modem mode then it'll be your router that sends the DHCP broadcast request through the SHub. The SHub just passes the packets through.

The reason you can't get a response from 192.168.100.1 when this DHCP fails is that your router no longer has a valid WAN side IP and thus can't provide IP based communication with the SHub.

Are you running in modem mode?

[qasdfdsaq]

Originally Posted by Eeeps

If you are operating the SHub in modem mode then it'll be your router that sends the DHCP broadcast request through the SHub. The SHub just passes the packets through.

The DHCP messages in both modes relate to the DOCSIS 3 DHCP process, and not the one the user sees on their end devices.

Even in router mode there is a second DHCP process that gives the router side an internet address.

[carbon60]

Thanks for your replies. What would be the next step in getting this looked at? If I call Support all I'm going to get is "Switch it off and on again" which temporarily fixes it.

[cdaly64504]

Possibly wait for the new Super hub R36 firmware would be your best bet.