What's new

Cable Modem Diagnostics Page Scripts Blocked - In 386.7 and 386.7.1 only

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ClockerXP

Occasional Visitor
Hello-
I have a Netgear CM3050V EMTA cable modem. I'm currently running Merlin 386.5.2 on my RT-AC86U. If I try to upgrade to 386.7 or 386.7.2 of Merlin, access to my cable modem at 192.168.100.1 is all screwed up and I am unable to veiw the signal levels and all kinds of other options related to more full featured cable modems (that include a router) show up instead. I'm a beta tester for Netgear so I had access to their product engineers. I had several emails back and fourth with Netgear engineering and he determined that for some reason scripts that run on the cable modem were being blocked. I can literally turn this problem on and off just by switch between versions 386.5.2 and (386.7 or 386.7.2).

Also, if I want to exhibit the same problem accessing the cable modem diagnostic screen on 386.5.2 all I have to do is enable Web apps and filters under Parental Controls.

So, it seems that under 386.7 & 386.7.2, even though I have Parental Controls / Webb apps and filters disabled in the GUI, it really isn't disabled. Anyone have a similar issue? Any suggestions?

Thanks,
CxP
 
Last edited:
Nope 386.7.2 no issues accessing my cable modem at 192.168.100.1
 
Nope 386.7.2 no issues accessing my cable modem at 192.168.100.1
Thanks. Can you let me know what modem model/brand? Netgear? Does enabling Parental Controls / Webb apps block your access to the admin page?
 
Last edited:
Thanks. Can you let me know what modem model/brand? Netgear? Does enabling Parental Controls / Webb apps block your access to the admin page?

My modem is a Arris SB8200 and i don't use Parent controls or Webb apps blockers.
 
Hello-
I have a Netgear CM3050V EMTA cable modem. I'm currently running Merlin 386.5.2 on my RT-AC86U. If I try to upgrade to 386.7 or 386.7.2 of Merlin, access to my cable modem at 192.168.100.1 is all screwed up and I am unable to veiw the signal levels and all kinds of other options related to more full featured cable modems (that include a router) show up instead. I'm a beta tester for Netgear so I had access to their product engineers. I had several emails back and fourth with Netgear engineering and he determined that for some reason scripts that run on the cable modem were being blocked. I can literally turn this problem on and off just by switch between versions 386.5.2 and (386.7 or 386.7.2).

Also, if I want to exhibit the same problem accessing the cable modem diagnostic screen on 386.5.2 all I have to do is enable Web apps and filters under Parental Controls.

So, it seems that under 386.7 & 386.7.2, even though I have Parental Controls / Webb apps and filters disabled in the GUI, it really isn't disabled. Anyone have a similar issue? Any suggestions?

Thanks,
CxP

Have you tried a full factory reset after upgrading to 386.7? Maybe some old config is stuck and getting enabled, blocking web apps even though you have it deselected?
 
Have you tried a full factory reset after upgrading to 386.7? Maybe some old config is stuck and getting enabled, blocking web apps even though you have it deselected?
Thanks! The full factory reset did the trick. Unfortunately I had to re-do all my settings, port forwarding, dns, vpn, etc. because reloading a config file created in 385.2 or 387.x resulted in the same problem. Nonetheless..everything's good now. It had been forever since I did a factory reset so it was probably due anyway.
 
Thanks! The full factory reset did the trick. Unfortunately I had to re-do all my settings, port forwarding, dns, vpn, etc. because reloading a config file created in 385.2 or 387.x resulted in the same problem. Nonetheless..everything's good now. It had been forever since I did a factory reset so it was probably due anyway.

Yeah it's a necessary evil to do it, at the very least when you go up a major release (like 384 to 386) but also when there is some inexplicable issue.

Some stuff you can restore by exporting to a text file and reimporting but the best and safest is to just do it manually. As you saw, using a config backup is useless.
 
Tried everything here-Factory resets, ASUS stock trx, rollback to 386.5.2, then back to factory default reset on 7.2...nothing allowed access to 192.168.100.1 .
The only way to access the netgear cable modem at that address is to plug the modem into the pc, totally bypassing the router. Then, and only then, am I able to get that address to resolve.
While I haven't changed the router LAN - DHCP Server range (253 addresses-the max allowed), in the past, the router would resolve the modem address without a problem. The last 3 or 4 iterations have cut that access off.

IP Pool Starting Address- 192.168.1.2
IP Pool Ending Address- 192.168.1.254

Any other ideas?
 
I believe this is quite normal - I only have access to 192.168.100.1 on my TC4400 (cable, connected to WAN) during the first couple of minutes. After that you need this:

I'm using this static route to access it:
1663716230094.png


You'll need to deactivate then reactivate static routes ones in a while to regain/retain access, but it works every time.

Edit: I think the modem releases its announcements (or whatever) on its LAN interface once there's a connection and you need to manually add the route.
 
I believe this is quite normal - I only have access to 192.168.100.1 on my TC4400 (cable, connected to WAN) during the first couple of minutes. After that you need this:

I'm using this static route to access it:
View attachment 44327

You'll need to deactivate then reactivate static routes ones in a while to regain/retain access, but it works every time.

Edit: I think the modem releases its announcements (or whatever) on its LAN interface once there's a connection and you need to manually add the route.

That static route pointing to itself does nothing. Only thing I can think is maybe it is forcing an ARP request and keeping it active somehow, but your default route should do that as well.

The modem doesn't announce anything, it essentially "intercepts" traffic destined for that IP passing through it, so maybe some modems only allow that for a couple minutes for security reasons? But if adding the static route makes it work, then that doesn't appear to be the explanation. Maybe disabling and re-enabling forces a refresh of the ARP table and that does something to wake up the modem's management interface.

Have never had an issue accessing that page on several brands of modems, but haven't tried every brand.
 
Tried everything here-Factory resets, ASUS stock trx, rollback to 386.5.2, then back to factory default reset on 7.2...nothing allowed access to 192.168.100.1 .
The only way to access the netgear cable modem at that address is to plug the modem into the pc, totally bypassing the router. Then, and only then, am I able to get that address to resolve.
While I haven't changed the router LAN - DHCP Server range (253 addresses-the max allowed), in the past, the router would resolve the modem address without a problem. The last 3 or 4 iterations have cut that access off.

IP Pool Starting Address- 192.168.1.2
IP Pool Ending Address- 192.168.1.254

Any other ideas?

After you did a factory reset, did you try before configuring anything other than basic settings? I'm thinking something like AIprotection, parental controls, etc could be interfering.

Are you using a PPPoE connection with your ISP? I've heard of that being an issue, I don't recall the workaround but I think it's been discussed here before.
 
That static route pointing to itself does nothing. Only thing I can think is maybe it is forcing an ARP request and keeping it active somehow, but your default route should do that as well.

The modem doesn't announce anything, it essentially "intercepts" traffic destined for that IP passing through it, so maybe some modems only allow that for a couple minutes for security reasons? But if adding the static route makes it work, then that doesn't appear to be the explanation. Maybe disabling and re-enabling forces a refresh of the ARP table and that does something to wake up the modem's management interface.

Have never had an issue accessing that page on several brands of modems, but haven't tried every brand.
I've had this issue with the AX58U and the AX86U with the TC4400; the route gets lost somehow, pretty much independent of the firmware. I believe this is due to the WAN handling on the router.

I'm not trying to tell you you're wrong, but how I've been able to circumvent this. (Re-) Apply the static route and it works again for one reconnect.
 
Last edited:
I've had this issue with the AX58U and the AX86U with the TC4400; the route gets lost somehow, pretty much independent of the firmware. I believe this is due to the WAN handling on the router.

I'm not trying to tell you you're wrong, but how I've been able to circumvent this. (Re-) Apply the static route and it works again for one reconnect.

Your default route (which points all traffic except your LAN subnet to the WAN) covers 192.168.100.1 so that static route isn't doing anything routing wise. It may be overcoming some sort of glitch or bug though.

Are you using PPPoE for your ISP connection? It is possible that static route is forcing the modem traffic to bypass the PPPoE tunnel, whereas your default route is telling all traffic to go to the tunnel.
 
Your default route (which points all traffic except your LAN subnet to the WAN) covers 192.168.100.1 so that static route isn't doing anything routing wise. It may be overcoming some sort of glitch or bug though.

Are you using PPPoE for your ISP connection? It is possible that static route is forcing the modem traffic to bypass the PPPoE tunnel, whereas your default route is telling all traffic to go to the tunnel.
It's cable/DOCSIS. Again, no idea, why, but after a WAN reconnect, setting this static route allows me to connect to my modem, which exclusively listens on 192.168.100.1.
 
It's cable/DOCSIS. Again, no idea, why, but after a WAN reconnect, setting this static route allows me to connect to my modem, which exclusively listens on 192.168.100.1.
Some cable providers do use PPPoE (username and password in the router) which is why I ask. Without looking in the CLI and poking around can't really do more than guess unfortunately.
 
After you did a factory reset, did you try before configuring anything other than basic settings? I'm thinking something like AIprotection, parental controls, etc could be interfering.

Are you using a PPPoE connection with your ISP? I've heard of that being an issue, I don't recall the workaround but I think it's been discussed here before.
I did exactly that, trying the address with the router only configured enough to let me access GUI...
Also, comcast doesn't use PPPoE connection with for my ISP. I'm at a loss...
 
I did exactly that, trying the address with the router only configured enough to let me access GUI...
Also, comcast doesn't use PPPoE connection with for my ISP. I'm at a loss...

I know plenty of people with Comcast (had it myself years ago for many years) and have never seen them disable their admin page after x minutes. Only guess is some bug with the Asus firmware not liking the private IP on the WAN port, or losing ARP entry for it, which the route keeps alive somehow. Guess it could be your particular model of modem that has something flaky too. Without doing CLI troubleshooting, hard to even guess. But luckily it isn't a page you need to hit that often and sounds like you have a workaround of sorts.

Edit - sorry it was the other poster that found a workaround. Maybe try adding that same static route on yours. Technically no reason why it should work, but worth a shot.

One other thing you could look into - I believe somewhere in your account you can tell it to send a reset signal to your modem - supposedly it does more than reboot, tells it to redownload config files etc (may or may not be true). Or you could ask their support to reset your modem as you think it may have a bad config etc.
 
I know plenty of people with Comcast (had it myself years ago for many years) and have never seen them disable their admin page after x minutes. Only guess is some bug with the Asus firmware not liking the private IP on the WAN port, or losing ARP entry for it, which the route keeps alive somehow. Guess it could be your particular model of modem that has something flaky too. Without doing CLI troubleshooting, hard to even guess. But luckily it isn't a page you need to hit that often and sounds like you have a workaround of sorts.

Edit - sorry it was the other poster that found a workaround. Maybe try adding that same static route on yours. Technically no reason why it should work, but worth a shot.

One other thing you could look into - I believe somewhere in your account you can tell it to send a reset signal to your modem - supposedly it does more than reboot, tells it to redownload config files etc (may or may not be true). Or you could ask their support to reset your modem as you think it may have a bad config etc.
Thanks for thinking this one over. I will do a reset, but I think it is just gonna have to be lived with for now. The moment that I rewire the modem directly to the PC, access works as before while using the router. I don't have the chops to figure this one out...thankfully, a rarity for me.
 
Thanks for thinking this one over. I will do a reset, but I think it is just gonna have to be lived with for now. The moment that I rewire the modem directly to the PC, access works as before while using the router. I don't have the chops to figure this one out...thankfully, a rarity for me.

Try the static route that the other person posted too, never know, may work. 192.168.100.1 via 192.168.100.1. Having that route in theory makes the router ARP for 192.168.100.1 from time to time so it might help. There is a way to add a static ARP via a script which would probably accomplish the same thing but this is easier to test.

I'm assuming you're rebooting the modem after swapping between PC and router each time (typically internet wouldn't work if you didn't but figured I'd ask)?
 
It's cable/DOCSIS. Again, no idea, why, but after a WAN reconnect, setting this static route allows me to connect to my modem, which exclusively listens on 192.168.100.1.

If you ever have a chance, find the MAC address for 192.168.100.1 by going into the CLI and doing "arp -a", then delete the static route and reboot the router, then log into the CLI again and set a static ARP entry for 192.168.100.1 using arp -s. See if you are able to connect to the modem, and if it keeps working long term. This won't survive a reboot unless you make it a startup script but would be curious if that works for you long term, if it does then you could move that command to a startup script to make it permanent and it would also be a potential solution for others. Of course if you ever replace the modem you have to update the MAC on the startup script, but not a big deal.

In the past it was fairly common to have to set static ARP entries in *nix based corporate firewalls. Not common anymore but it is the only thing I can think that your static route would be accomplishing, forcing that ARP entry to not age out.

Regardless it is still a bug somewhere, there is no reason your default route shouldn't allow your router to ARP out the WAN for the modem's management MAC address, but sounds like something isn't working quite right.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top