NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.

Forum Discussion

CrimpOn's avatar
CrimpOn
Guru - Experienced User
Oct 21, 2019
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 located telnetenable2, which claims to work with R7000.  The Windows version aborts with "Password too long."  The Linux version runs, but the R7000 does not respond to telnet.

 

Thanks

 

 

  • > [...] 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.

7 Replies

  • > 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.)

    • CrimpOn's avatar
      CrimpOn
      Guru - Experienced User

      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.

       

       

      • antinode's avatar
        antinode
        Guru

        > [...] 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.

      • antinode's avatar
        antinode
        Guru

        > Sorry, not there on my Nighthawk R7000.

         

           On mine, with V1.0.9.60_10.2.60, the page ("debug.htm") is there, but
        I see nothing about Telnet on it.

         

           After reverting to V1.0.9.42_10.2.44, "debug.htm" mentions Telnet,
        but only in code which was commented out.  (But a Telnet-enable program
        like NTE still worked with that version.)

         

           More examples of "continuous improvement", Netgear style.