NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Telnet on R7000?
Sorry if "this horse died a long time ago". After much searching, I am unable to determine that telnet can or cannot be enabled on the Nighthawk R7000, firmware 1.0.9.88_10.2.88 (current). I loc...
> [...] I had not realized that UDP would return an ACK. [...]
UDP itself doesn't, but the program which listens for the special
Telnet-enable message (Looks like "telnetDBGD" on my D7000) seems to.
(I didn't see it documented anywhere, but when I ran the experiment, I
detected a response when the request succeeded.> [...] NTE does not attempt to open a telnet session, [...]
That's not its job. All it does is send the Telnet-enable message.
If that works, then the router firmware should enable/run its Telnet
daemon ("/sbin/telnetd"). Then, a normal Telnet client will have
something with which to talk.> My conclusion (so far), is the current R7000 firmware isn't running
> telnet, or at least isn't listening on port 23. [...]
Right. A "connection refused" complaint from a Telnet client which
tries to connect to it would be another clue. By default, the router's
Telnet server is disabled, but these Telnet-enable programs are supposed
to send the magic Telnet-enable message which should persuade the router
to enable its Telnet server. And that's what's not happening.> [...] Not answering SSH, either.
I've never heard of a Netgear router allowing an SSH connection.
> [...] Do I need to scan all possible ports, and maybe Netgear put
> telnet or ssh somewhere else?I doubt that that would help. Many things are possible, but I
haven't seen any evidence that Netgear uses any odd-ball ports for this
stuff.Around here, on a handy D7000 (vaguely similar to an R7000), for
example:# ps | grep -i telnet 781 root 0 SW [ telnetDBGD ] 782 root 0 SW [ acktelnetDBGD ] 2178 root 616 S telnetenabled 10.0.0.1 506A03E9AE88 admin password 25785 root 1144 S /sbin/telnetd 27377 root 1140 S grep -i telnet
I know nothing, but I'd guess that the "telnetDBGD"+"acktelnetDBGD"
pair are what handle the Telnet-enable message (and the response to
it?), and "telnetenabled" is what actually enabled the Telnet daemon
("/sbin/telnetd").As for receptive ports:
# netstat -an | grep ' LISTEN ' tcp 0 0 0.0.0.0:33344 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:14369 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:20005 0.0.0.0:* LISTEN tcp 0 0 10.0.0.1:1990 0.0.0.0:* LISTEN tcp 0 0 10.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::23 :::* LISTEN
All of which, although potentially interesting, tells us nothing
about why this stuff stopped working when it did, or whether that
change was intentional, or just another recently introduced bug.> [...] my hope is that someone on the forum has the expertise to put me
> out of my misery.Sadly, loading older firmware may be all that I can suggest.
Waiting for a useful response from Netgear to complaints here about an
unsupported feature doesn't seem to have been very productive so far.
> After much searching, [...]
Where?
> [...] I am unable to determine that telnet can or cannot be enabled on
> the Nighthawk R7000, firmware 1.0.9.88_10.2.88 (current).
All the evidence which I've seen suggests that Netgear broke it a
while ago. See, for example:
https://community.netgear.com/t5/x/x/m-p/1786837
> [...] The Windows version aborts with "Password too long." [...]
How long is it? I believe that the limit in these programs is 32
characters.
> [...] The Linux version runs, but the R7000 does not respond to
> telnet.
An advantage of my NTE program is that it listens for a response from
the target device, and thus is better able to distinguish success from
failure. (But I'll admit that knowing immediately that it failed is not
vastly superior to discovering later that it failed.)
THANK YOU for commenting. I have searched Google, Netgear, user forums, OpenWRT, etc. and everything points to:
- A "debug" option which no longer exists
- A "debug" option which existed, but was commented out. (no longer exists, even as a comment)
- Telnetenable, for Linux and for Windows 10
- Your NTE program (thanks for the link)
I just installed NTE and got "No ACK message received". I had not realized that UDP would return an ACK. Wireshark clearly shows NTE sending the one UDP packetd. Then, my computer ARP's "who has this IP". The R7000 answers, "IP is at my MAC". And, that's it. NTE does not attempt to open a telnet session, so I guess it was expecting an ACK because of the UDP packet and aborted.
My conclusion (so far), is the current R7000 firmware isn't running telnet, or at least isn't listening on port 23. Not answering SSH, either.
Oh, geez. Do I need to scan all possible ports, and maybe Netgear put telnet or ssh somewhere else?
Thank you, again. Floundering for a couple of hours is really frustrating and my hope is that someone on the forum has the expertise to put me out of my misery.
> [...] I had not realized that UDP would return an ACK. [...]
UDP itself doesn't, but the program which listens for the special
Telnet-enable message (Looks like "telnetDBGD" on my D7000) seems to.
(I didn't see it documented anywhere, but when I ran the experiment, I
detected a response when the request succeeded.> [...] NTE does not attempt to open a telnet session, [...]
That's not its job. All it does is send the Telnet-enable message.
If that works, then the router firmware should enable/run its Telnet
daemon ("/sbin/telnetd"). Then, a normal Telnet client will have
something with which to talk.> My conclusion (so far), is the current R7000 firmware isn't running
> telnet, or at least isn't listening on port 23. [...]
Right. A "connection refused" complaint from a Telnet client which
tries to connect to it would be another clue. By default, the router's
Telnet server is disabled, but these Telnet-enable programs are supposed
to send the magic Telnet-enable message which should persuade the router
to enable its Telnet server. And that's what's not happening.> [...] Not answering SSH, either.
I've never heard of a Netgear router allowing an SSH connection.
> [...] Do I need to scan all possible ports, and maybe Netgear put
> telnet or ssh somewhere else?I doubt that that would help. Many things are possible, but I
haven't seen any evidence that Netgear uses any odd-ball ports for this
stuff.Around here, on a handy D7000 (vaguely similar to an R7000), for
example:# ps | grep -i telnet 781 root 0 SW [ telnetDBGD ] 782 root 0 SW [ acktelnetDBGD ] 2178 root 616 S telnetenabled 10.0.0.1 506A03E9AE88 admin password 25785 root 1144 S /sbin/telnetd 27377 root 1140 S grep -i telnet
I know nothing, but I'd guess that the "telnetDBGD"+"acktelnetDBGD"
pair are what handle the Telnet-enable message (and the response to
it?), and "telnetenabled" is what actually enabled the Telnet daemon
("/sbin/telnetd").As for receptive ports:
# netstat -an | grep ' LISTEN ' tcp 0 0 0.0.0.0:33344 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:14369 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:20005 0.0.0.0:* LISTEN tcp 0 0 10.0.0.1:1990 0.0.0.0:* LISTEN tcp 0 0 10.0.0.1:53 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:631 0.0.0.0:* LISTEN tcp 0 0 :::80 :::* LISTEN tcp 0 0 :::23 :::* LISTEN
All of which, although potentially interesting, tells us nothing
about why this stuff stopped working when it did, or whether that
change was intentional, or just another recently introduced bug.> [...] my hope is that someone on the forum has the expertise to put me
> out of my misery.Sadly, loading older firmware may be all that I can suggest.
Waiting for a useful response from Netgear to complaints here about an
unsupported feature doesn't seem to have been very productive so far.Thank you again for being patient with me. I did scan TCP through 64000 and a few TCP ports are open, but none respond to telnet.
I knew SSH was far fetched. It's the default on all my Linux machines, but no go here.
I just hope that Netgear doesn't turn off telnet on my Orbi. There are a host of useful things that telnet makes possible on the Orbi.
As for my R7000. "Oh, well."