@Gihad fwiw, the modems are far more reliable than customers and tech support believe. The actual failure rates don't justify swapping modems out in an attempt to solve cable issues. That just leads to aggravation on everyone's part.
There is no good reason for a modem to reboot randomly, except for:
1. instances where the modem has lost communications with the Cable Modem Termination System (CMTS), usually caused by external cable failures; or
2. overheating, if the modem isn't parked in a location with adequate ventilation.
My bet is on an external cable fault, which might be intermittent at this point. The external cable from the house to the local tap is the Achilles heal of cable networks, requiring routine replacement after it degrades beyond a certain point. If it just failed once and for all, it would be much simpler to determine and replace. Instead, it fails on an intermittent basis, until one day, it simply dies. That intermittent failure phase can be hard to determine and very frustrating, to say the least.
Ok, step one, logging into the modem. With the modem in Gateway mode, use 192.168.0.1. With the modem in Bridge mode, use 192.168.100.1
If the modem doesn't respond to your login attempts, thats an indication that it has version 7.x loaded. That version becomes unresponsive to user login attempts after a period of time, days, weeks, haven't tracked it down exactly. Unplug the modem from the wall socket, wait for 10 to 15 seconds and then plug it back in again, forcing a modem reboot/restart.
Unfortunately, that modem restart also resolves cable issues, at least on a temporary basis. I'd like to see the modem's signal levels after a period of time has passed, but, for now:
1. log into the modem and navigate to the STATUS .... DOCSIS WAN tab.
2. select the modem signal table, from the start of the "Downstream Overview" line, all the way to the bottom right hand corner of the bottom OFDM/OFDMA Overview. Park the curser at the beginning of the Downstream Overview line, hold down the left mouse button and scroll down to the very bottom right hand corner of the table. You can also use the arrow keys to move down and right, to do the same thing. When that table is selected, copy it, right click .... Copy.
3. then in a new post, right click .... Paste. The end result should look like the table from the modem's UI.
As I indicated above, the modem reboot will cause the signal data to look pretty good, unless there is something really amiss with the external cable. So, we'll see how it looks. I like to see the same table after several hours have passed, maybe even after a day or to, just to compare the before and after levels. The second login to do this should not require a modem restart. In fact, I need to see those starts without a modem restart, just to see how they look after several hours or possibly days after a modem restart
Next step. Even with good signal levels, its possible to have cable problems that don't show up in the signal data. If you're seeing service disruptions, that can happen fast enough that they won't show up in the signal data, or perhaps the event log. You indicted that you were seeing only one in fifty pings actually succeed. There's definitely a problem with that. Are you running a ping test via wifi or ethernet, and what's the ping target?
In order to look for an external cable problem, beyond the signal data, you need to run a ping test to the CMTS. To do that, run a trace to anywhere. On a windows pc or laptop, go Start and enter cmd in the Search box to bring up a command prompt. Type in:
tracert -4 www.google.com
With the modem in Gateway mode, or a modem in Bridge mode with a router behind it, the first Hop IP address will be the modem (Gateway mode) or router (modem in Bridge mode). The second Hop IP address is the CMTS. Ping the CMTS for at least an hour using an ethernet connected pc or laptop.
Ping -n 3600 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the CMTS IP address (Hop #2 IP address)
That will run for one hour and then terminate. Copy the bottom results and paste them into a post. Left mouse button down, and scroll down from the first results line, to include all of the bottom results. Use Ctrl c to copy the selected data to the clipboard and then paste them into a post.
You shouldn't see anymore than a handful of packets lost for a 24 hour test, so for a short 1 hour test you should only see one or two packets lost.
If you wanted to run a much longer ping test, then use:
ping -t xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the CMTS IP address (Hop #2 IP address)
You would need to use Ctrl c to bail out of the test at any point.
If you wanted to run a 24 hour test, use:
Ping -n 86400 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the CMTS IP address (Hop #2 IP address)
Ok, with the signal data and ping test results, that will hopefully point out the problem.
Just to note, I've had a 4582 running for almost four years now, without any problem. If I do run into any issues, my first thoughts are to check the signal levels and ping results from the CMTS, looking for potential problems with the external cable. That 4582 sits on the far edge of my desk, where there isn't any issue with ventilation for the modem.
One other thought, if you have IPV6 running, where the modem's router mode is set to Dual (IPV4 and IPV6), strongly consider setting the BASIC .... GATEWAY FUNCTION .... Router Mode to IPV4. The modem will take a couple of minutes to sort itself out, but, I will usually run a modem reboot as well, which is located in ADMIN .... DEVICE RESET .... Reboot. There are sporadic IPV6 issues with the CMTS which keep popping up from time to time, so, setting the modem to IPV4 only will avoid those issues. Not saying that's the problem here, but, one way to avoid potential IPV6 issues is to simply disable it. That's unfortunate given the growing use of IPV6, but, it is what it is.
Fwiw, my better half gives presentations, participates in panel discussions and other group online meetings as required, all done via ethernet connected laptop, with the 4582 in Bridge mode and the router running IPV4 only. That configuration has been rock solid, even with the pandemic loads at the neighbourhood node and CMTS.
Is your wife connecting to the modem via ethernet or wifi? If it's wifi, there are other suggestions for wifi settings that I can provide.
For now, assuming that there's a cable fault at hand, prior to starting something important such as an online conference, unplug the modem, wait for 10 to 15 seconds and then plug it back in, forcing a modem restart/reboot. That should result in stable performance for the required time period, unless of course, there is something very wrong with the external cable and its connectors.
Would you happen to know when the external cable was replaced, and, do you have underground cabling or an overhead cable running from a nearby utility pole. Underground or overhead, the cable still requires replacement after a number of years. That could range anywhere from after two years to somewhere around 10 to 15 years, perhaps longer.
Hey @Eli_Sand!
Thanks so much for sharing your concern with the inability to access the modem's GUI without a reboot after some time. I've experienced this myself though it's important to note that the MyWiFi app is available and is available for use in lieu of the modem GUI. I do appreciate the preference here and the necessity of logging in to validate your signal levels.
There's quite a few things to validate to ensure we can narrow down what's causing it for anyone experiencing this issue and is able to complete the steps. I understand it's not possible for all.
- Ensure the WiFi app has not been connected. Factory Restore the modem if it has. Do no reconnect the app.
- Connect a single wired device to the modem, with no 3rd party equipment.
- Ensure the modem is in Gateway mode, not Bridge mode
- Test the GUI log in 24 hours after a modem reboot/restore.
If the issue persists than this narrows down the issue considerably. Thank you so much.
Thanks @Eli_Sand.
If the modem is in bridge mode then user access to the GUI should be restricted. To my knowledge this is normal if you're unable to access it. Definitely let us know though if you have any further questions.
@RogersAndy @Eli_Sand thats not true. Access to the modem's UI has always been available when the 4582 is in Bridge mode. Otherwise, you would always have to run a manual factory reset to switch from Bridge mode to Gateway mode. So, the modem's UI is available when the 4582 is in Bridge mode. Only difference is that the number of functions that are available are reduced to a minimum, consistent with the function of the modem as a modem only, without firewall, DHCP server, wifi, etc, etc.
I just logged into my 4582 after 42 days of operation in Bridge mode. The modem's UI was available and there wasn't any problem logging into the modem using 192.168.100.1
In the event the the modem doesn't respond to a log in attempt, a modem restart will solve the issue, as in pull the power, wait for 10 to 15 seconds and plug it back in. Only real problem at this point is that a modem restart will cause the signal levels to look normal, at least for a period of time. So, the only way to determine the signal levels, when you're having problems is to ask tech support to look at them, without any recent modem restart.
Fwiw .....
Edit: Note that the problem of the 4582 not responding to a login attempt is a recent occurrence with the update to version 7.x. @RogersIan had indicated that this problem should be resolved in version 7.1.1.33, but, from my interactions with the 4582's login in page, I don't believe that this problem has been resolved.
Also note that the DOCSIS EVENT log at this time is empty. If I reboot the modem, the DOCSIS EVENT log will display the previous logged events, as it should. This is yet another problem with version 7.x
-
29100 views
-
12 Likes
-
-
