RBS40V?
CrimpOn opened this issue · 8 comments
Have not been successful in enabling telnet on Orbi RBS40V (Voice).
It is pretty obvious that this speaker-enabled hybrid is "different" in many ways, such as the image file extension being "chk" rather than "img". Is there a way to enable diagnostics on the Python script that might indicate how it is failing? The output seems to indicate success:
C:\Users\Dick>netgear_telnet-main\telnet-enable2.py 192.168.1.70 3C:37:86:43:14:1C admin mypassword
Netgear LBR20 Telnet enabler V2 LBR20(c) B.Kerler 2021
Done sending pw data to 192.168.1.70:23
Done sending hashed_pw data to 192.168.1.70:23
I get the same output on my RBR750 (Firmware Version V4.6.5.14_2.0.54) but still no telnet. I've seen a few other posts from people who have had success on an RBR850. Thank you for all your effort on this @bkerler! I feel so close to having telnet back. :)
Do you have links to those comments about the RBR850? It would be helpful to confirm that they are using this Python script rather than some other method.
It's hard to tell without having the binaries to reverse ;) Also I get almost no replies from people using the script when it works.
The script is magic for me. With firmware V2.7.3.22 Netgear removed the telnet option from the debug screen on my Orbi. This script is what is keeping me on stock Netgear firmware rather than moving to Voxel's version. I wanted to poke around in the RBS40V and just got nowhere.
The reason I mention a debugging option is that the TFTP protocol appears to include asking permission to write, numbered ACK's, etc.https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol
I can probably hack away at the script and hope that I don't break it in the process.
I have a suspicion that this wonderful script is doing something very important to "enable" telnet, but not what I had imagined.
i.e. the script connects to port 23 (telnet) on the target IP. That implies (to me) that some process is already listening on port 23 and accepts the connection. Until this script is run, any attempt to make a telnet connection using PuTTY gets a network error: "connection refused". After the script is run, PuTTY connections are successful. Does telnet have multiple states: (a) accept connections but do not respond, and (b) accept connections and respond?
Very confused.
Something a more sophisticated Python user would have noticed: Netgear leaves a process running on the router waiting for a UDP stream to arrive on port 23. (not the regular Telnet TCP connection.) UDP needs no connection. The process looks for that "Magic Packet" and enables telnetd once the correct packet has been received.
This script that works so well on earlier Netgear routers fails on newer routers. The issue
appears to be a totally different Magic Packet.
Alas, my Python skills are FAR superior to my ability to work with binary files. I hope that the telnetenabled daemon for the RBS40V is attached.
telnetenabled.zip