Telnet on R7000?

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