This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I have a simple well tested telnet script to reboot the router that executes automatically on a daily basis. I have enabled telnet using 192.168.1.1/debug.htm but note that once the router reboots, telnet is again disabled and would need to be re-enabled for the script to run again.
Is there a way to permanently enable telnet on the Orbi?
Tech support basically stated that they were concerned about using telnet on the Orbi, fearing that I could "brick" the router and didn't offer any meaningful help.
Alternatively, is there a way to schedule a regular automatic reboot on the Orbi?
Oh, that is a frustrating "gotcha". Executing the telnet script makes it impossible to execute the script again.
I am not aware of anything in the Orbi that provides for automatic reboot on a schedule.
Another possibility is to automate a script to use the web interface to reboot. i.e.
Connect to the Orbi
Enter the user ID and password
Click on the Advanced Tab
Click on Reboot
I got a huge number of hits on a Google search for how to automate web activity. My Orbi has been up for 98 days, so I am not looking to reboot until the next firmware update.
Yes..it is frustrating...I've used this scripts on other routers without any problem...I will look into web based automation but that sounds like work! LOL...I guess I'm more frustrated with the non-support offered by Netgear rather than a straightforward answer to my question. In the long run, it may not matter...I used this script for a router that was acting a little flaky and needed refreshing every day. So far the ORBI seems to be stable...we'll see..it's only been two days LOL
I am not currently having a problem..this script was associated with an older router that was dropping connections and stalling on a regular basis...but...your response really doesn't address the basic question I asked...either how to enable telnet on a regular basis or automate a reboot or some other process if I want.
So far, the web automation method suggested may be the way to go. I'm presently looking into that possiblity.
I have used the batch file below to successfully enable telnet on my DGND3700 from both 64 and 32 bit Windows 7 computers. Insert you LAN MAC for your DGND3700 instead of the row of *. My copy of 'telnetenable.exe' is at S:\netgear dgnd3700\telnetenable\telnetenable.exe. You will need to change this to where yours is stored. I created this batch as you need to re-do following each router re-boot.
Just a note. I was incorrect about the Windows telnetenable program. Although the C source code showed the password field being 10 characters long, the Windows program will actually accept passwords up to 16 characters, and my router password is actually 17 characters long. The Linux program did not complain about length, but it also did not work. Firing off a UDP packet is efficient, but creates no "connection", so there is no way to tell if the packet "did anything" or not.
I wasn't clear exactly how Telnetenable worked so your comment is helpful...You are right...it only shows the packet being sent...not whether it is successful...there is NO way to tell whether the router was "enabled" or not short of issuing the telnet command to find out.
Not to be flippant, but if the password length can not exceed 16 characters, why not change your password? LOL..my context is in my home wireless environment and the password is 8 characters and I'm not very concerned about being hacked but I can understand that in more commercial environment, a longer passcode might be warranted.
You are entirely correct. I will change the password and make another test - although I have already tried the Linux version which accepts passwords longer than 16 characters and also failed. (I must also confess to another amateur blunder. The code said the password field was 0x10. Of course, this is hexadecimal and the decimal equivalent is 16.) In other versions of the code the password field is 0x21, which in decimal is 31. The field includes space for the string terminator character, so the maximum password used to 15 and now it is 32.)
I have opened a post over in the R7000 user forum and so far no one has commented. My "fear" is that Netgear responded to criticism of "telnet is not secure" on the Nighthawk line by simply shutting off telnet. And, that they will do the same thing to the Orbi line. Losing command line access to the router removes access to looking at critical information to see "what is going ON???"
Well, made the password shorter, and that test failed as well. Looks like maybe Netgear really has disabled telnet on the Nighthawk R7000 routers.
I had originally looked into this as a way of validating that this mechanism worked on the Orbi line and could be used as a replacment for using the "debug" web page to turn on telnet automatically. Got side-tracked because I also have the Nighthawk in AP mode. "Oh, fudge."
Just wondering...I found that the syntax for the MAC address parameter on the telnetenable executable is very particular and case sensitive. If you use lower case letters instead of upper case, the script does NOT work properly...additionally, at least with the Windows version, the colons need to be removed from the MAC address...so the correct syntax would be:
That is good news...maybe in a later firmware update, that will be fixed for those of us using the RBR50/RBS50. In the meanwhile, I have been able to successfuly merge the telnetenable script into my own reboot script and it seems to be working fine.
