janpoe's profile

New Contributor

 • 

6 Messages

Closed

Connection Drops with Netgear cg3000d usally once a day

Connection Drops with Netgear cg3000d usally once a day. I still show wireless connection when this happens but

no internet. I have 2 computers on the Network, on wired and one wireless. The other day when it happened, the wired connection did not have internet but my wireless one did. Usually the connection issue is related to the wired computer. Yesterday for the first time it was related to the wireless computer. The wired computer has a static IP and I restricted the DHCP ips to below the static IPs.

Here is the latest log...

11:31:27 2013 Warning (5) Admin login authentication fail
Wed Aug 07 09:13:54 2013 Error (4) DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Wed Aug 07 04:51:21 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Wed Aug 07 04:50:50 2013 Warning (5) MDD message timeout;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Wed Aug 07 04:50:46 2013 Critical (3) SYNC Timing Synchronization failure - Failed to receive MAC SYNC frame within time-out period;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Wed Aug 07 04:26:58 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Aug 06 21:13:54 2013 Error (4) DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Aug 06 19:02:52 2013 Warning (5) Admin login authentication fail
Tue Aug 06 09:14:38 2013 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Aug 06 09:13:57 2013 Notice (6) TLV-11 - unrecognized OID;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Aug 06 07:01:34 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Mon Aug 05 18:35:48 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Sun Aug 04 21:36:45 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Sun Aug 04 08:34:07 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Sun Aug 04 05:52:09 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Sat Aug 03 01:50:16 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Thu Aug 01 18:48:55 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Thu Aug 01 03:32:43 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Jul 30 20:00:47 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Jul 30 07:23:18 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Jul 30 03:05:25 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Mon Jul 29 16:00:10 2013 Critical (3) Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Mon Jul 29 02:37:36 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Sun Jul 28 06:16:10 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Thu Jul 25 21:19:19 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Thu Jul 25 01:35:45 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Tue Jul 23 22:20:57 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Mon Jul 22 12:52:39 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Sat Jul 20 22:14:40 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Fri Jul 19 22:56:48 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Fri Jul 19 09:12:17 2013 Critical (3) Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0;
Time Not Established Warning (5) DHCP WARNING - Non-critical field invalid in response ;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.0;CM-VER=3.0;

--------------------------------------------------------------------------------

Contributor III

 • 

806 Messages

First thing I see are escalating T3's. A decent majority seem to happen between 19:00 and 22:00 hours. I am not sure what to think about the wired offline and wireless online symptom, maybe your wireless is roaming to another wifi or maybe there is a separate issue going on with the desktop, but I would start with the T3. Do they line up around the time you are having the issue? Also what are you signal levels?

New Contributor

 • 

6 Messages

The connection issue is usually first thing in the am. What is the T3 time out...not sure why there would be so many of them...signal levels seam to be good and the most of the connection issues are with the wired desktop connection, raely with my wireless laptop...thks for the reply

Contributor III

 • 

806 Messages

Short answer: What are you signal levels? Can you copy/paste them here? And here is a good break down of Transmit Errors.

http://volpefirm.com/docsis_timout_descriptions/

Long Answer:
Basically DOCSIS works by constantly checking the stability of the signal between your modem and the Cable modem termination system (CMTS). CMTS is like the head honcho as far as the modem is concerned. The modem uses it as a light house to make small adjustments to itself so it can keep the flow of data stable. It does this by constantly sending little signals to the modem, and waiting for a reply. Based on what it hears back from the modem, how long it takes to hear it, and if it doesn't hear it, it suggest corrections to the modem. If the modem doesn't correct itself, or can't, it registers a error. The conditions of that error determine the type of error(See break down in link) Kind of a over simplification and not entirely accurate, but best I can do. Its actually pretty complicated stuff.

As for whats causing YOUR T3, its hard to say. There is no one culprit, but there are likely suspects. Usually its a signal problem. It can also be power issues caused by either your outlet, the power brick or the transformer out in the pole. Or it can be the modem overheating or malfunctioning. Or it can be the equipment that is conditioning the cable signal on the line. Or it can be ingress leaking in somewhere causing the particular frequency you are using to degrade. But making sure your signal levels are perfect is a great first step.

I think you might help to try to see exactly why you can't get online the next time it happens. Do you have any experience with using the command prompt with Ping? If you can focus on what is causing the problem, rather then just how to make the problem go away, it will help you solve the underlying issue. I can go into more detail but its probably simpler to start with your signal levels.

New Contributor

 • 

6 Messages

Thanks for the reply. .I am fairly computer literate and know how to ping. .where do you suggest I start. It appears that is not a wireless or internal network issue as the the network seems to be okay. .it's appears to be the internet signal I'm losing. .

 

Status
System Up Time 0 days 16h:38m:51s
Network Access Allowed
Cable Modem IP Address 10.144.122.89 
 

Startup Procedure
Procedure Status Comment
Acquire Downstream Channel 825000000 Hz Locked
Connectivity State OK Operational
Boot State OK Operational
Configuration File OK DEF001_vm2.0_d.cfg
Security Enabled BPI+
 

--------------------------------------------------------------------------------
 
Downstream Bonded Channels
Lock Status Modulation Channel ID Symbol rate Frequency Power SNR DOCSIS/EuroDOCSIS locked
Locked QAM256 97 5360 Ksym/sec 825000000 Hz -5.0 dBmV 39.5 dB DOCSIS
Locked QAM256 98 5360 Ksym/sec 831000000 Hz -5.3 dBmV 39.2 dB DOCSIS
Locked QAM256 99 5360 Ksym/sec 837000000 Hz -5.5 dBmV 38.7 dB DOCSIS
Locked QAM256 100 5360 Ksym/sec 843000000 Hz -5.7 dBmV 38.9 dB DOCSIS
Locked QAM256 105 5360 Ksym/sec 873000000 Hz -4.9 dBmV 38.6 dB DOCSIS
Locked QAM256 106 5360 Ksym/sec 879000000 Hz -4.9 dBmV 38.6 dB DOCSIS
Locked QAM256 107 5360 Ksym/sec 885000000 Hz -5.1 dBmV 38.3 dB DOCSIS
Locked QAM256 108 5360 Ksym/sec 891000000 Hz -5.5 dBmV 38.2 dB DOCSIS
 

--------------------------------------------------------------------------------
 
Upstream Bonded Channels
Lock Status Modulation Channel ID Symbol rate Frequency Power
Locked ATDMA 3 5120 Ksym/sec 36100000 Hz 36.3 dBmV
Locked TDMA and ATDMA 1 2560 Ksym/sec 23300000 Hz 33.5 dBmV
Locked ATDMA 2 5120 Ksym/sec 29600000 Hz 35.0 dBmV
Unlocked Unknown 0 0 Ksym/sec 0 Hz 0.0 dBmV
 

--------------------------------------------------------------------------------
 
Current System Time:Thu Aug 08 09:23:49 2013
 
 

Contributor III

 • 

806 Messages

First thing I notice is low upstream power levels. Now its kind of complicated, but as I understand it, a low upstream is only a issue if your Upstream Signal to Noise(SNR) is also low. I could go into more detail, but it would just bore everyone, and the whole subject is kind of debatable.  Long story short, first thing you should do is call Cox (or if a Mod here can check) and have them check your Upstream SNR. If its low, and specifically if its low in your entire area, chances are there is a noise issue.If the area looks good, and its just your SNR that is low, then it is likly either a issue at your pole or some wiring problem in the house. If your US SNR is high, then your fine, and that isn't what is causing the Transmit Errors.

With that said, I don't think that is your only problem. Any problem with the US SNR would cause a internet problem that would effect ALL your computers, not just wired. Now I am assuming when you have the problem with Desktop, and not wireless laptop, that the wireless laptop is connecting to your router, and not a different network, and that your laptop doesn't have any other way of getting online (Cell, tether, phone hotspot, etc). If so, then if your wireless is going online and your wired isn't, then it must either be a problem with the Desktop, or a problem from the router to the desktop.  That is where the pinging comes in.

When the Desktop next goes offline, open up a command prompt and try the fallowing commands.

Ping 127.0.0.1

IPconfig (Note the "Default Gateway" IP we will say for the moment its 192.168.1.1)

Ping -n 25 192.168.1.1

Ping -n 25 192.168.100.1

Ping -n 25 Pop.cox.net (Or your WAN's gateway IP or DNS if you can find it)

Ping -n 25 8.8.8.8

Ping -n 25 Google.com

If time is a issue, like if the problem only happens for a short time, you can exclude the "-n 25" part. That just makes it ping more then the default 4 incase the problem is packet loss and not general loss of connectivity. What that is doing is pinging each hop as it goes from OS > NIC > Router > Modem > Inside Cox network > Outside Cox network. Then its just a matter of seeing where it fails and how it fails. Reply with the results and I can tell you what they mean, if not self explanatory. 

Valued Contributor

 • 

755 Messages

Based on the logs and what we can see here the signal levels appear to be in a working range, though the upstream is high it is in spec with the rest of the readings from the log. Being the wireless stays up and still allows you to connect the issue would not be with connectivity to the internet but something with the ethernet connection for the router side of the Netgear. The steps Trikein gave for pinging each connection used will give you really accurate information, but if the connection is not down log enough to run each of the tests for the computer all the way out to Google or another site that responds to pings,  you can run a tracert to www.google.com and it will give a summary of what he is trying as well and will be a faster response, and if its not specific enough it would allow us to single out one or two of the pings to run when it happens.

Contributor III

 • 

806 Messages

I didn't suggest a tracert because I find that adds confusion because of false negatives caused some hops not responding (or delaying a response) to ICMP. I also suspect maybe a DNS or browser issue, and thats why I wanted to ping both domain and IP.But you are right, a tracert would be faster and probably work better to give a broader understanding of the network in general. 

But what is his US SNR if I may ask? His US isn't high at 34-36, if anything that is low, and considering the modem logs show transmit errors, I think that is the best place to start.

New Contributor

 • 

6 Messages

Here is the tracert I ran remotely from work. I will try pinging the other IP's when I get home tonight. FYI, typically a router reset will fix the problem temporarily.

 his.com ping Gateway 

Ping Output
FROM www.his.com TO www.google.com.

PING www.google.com (74.125.228.80): 56 data bytes
64 bytes from 74.125.228.80: icmp_seq=0 ttl=58 time=4.962 ms
64 bytes from 74.125.228.80: icmp_seq=1 ttl=58 time=4.950 ms
64 bytes from 74.125.228.80: icmp_seq=2 ttl=58 time=5.567 ms
64 bytes from 74.125.228.80: icmp_seq=3 ttl=58 time=5.084 ms
64 bytes from 74.125.228.80: icmp_seq=4 ttl=58 time=4.499 ms

--- www.google.com ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 4.499/5.012/5.567/0.341 ms

 

New Contributor

 • 

6 Messages

Let rephrase my previous FYI statement....typically it necessitates a router reset to fix the problem

Contributor III

 • 

806 Messages

No, I meant to do it while the problem is occurring. But nevermind, I am going to let Edward take the lead on this one. Good luck.

New Contributor

 • 

6 Messages

Trikein, thanks very much for your help...I really appreciate it.

This morning was another router reset as we had no internet as usual first thing in the AM when booting up the desktop. I was unable to perform the diagnostics as you recommended as I had to leave for work. I did check my log and here is what coincides with start up the desktop

 Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0; 
 Fri Aug 09 07:41:41 2013    Notice (6)   TLV-11 - unrecognized OID;CM-MAC=28:c6:8e:33:56:18;CMTS-MAC=00:0e:83:06:29:4c;CM-QOS=1.1;CM-VER=3.0; 

 

 

Former Moderator

 • 

7.1K Messages

Trying a trace route when you're experiencing the problem may show where the connection is breaking down too.  Something like tracert 8.8.8.8 for example.

Recent Discussions