Telnet support
-
Yes we could add Telnet support and I will if there is enough demand (unless someone else does it first). However, Telnet is a very insecure protocol, not at all the sort of thing that I want running on my network, let alone on a WiFi connected device. One of the high priorities on my list is to improve the http security.
-
The issue, as I understand, with using SSH (which we should instead of telnet for security reasons) is the overhead implementing the SSH protocol on the ESP. I have not looked into this and David has so no doubt he can add more detail.
-
Huh? I've been a network engineer at a fortune 500 practically all of my professional life, and I work on network and VOIP equipment every day that supports and often requires telnet for configuration and maintenance! It's not supposed to be exposed to your internet gateway, that's why you keep your LAN protected behind a firewall. Besides, it's really no less secure than non-encrypted http. In fact, besides using a different port how is it any different then the clear text communication between a web browser and web server? Unless you're planning on using SSL on the DuetWifi there isn't any difference.
As far as SSH, yes I agree that would be great–but certainly not required since as I said the Duet should be used behind a firewall anyway.
If you're worried about it being insecure, why not make it a configurable option that can be disabled when not wanted?
Please don't make the DuetWifi the Windows 8 of 3D printer controllers....
Dieter
Yes we could add Telnet support and I will if there is enough demand (unless someone else does it first). However, Telnet is a very insecure protocol, not at all the sort of thing that I want running on my network, let alone on a WiFi connected device. One of the high priorities on my list is to improve the http security.
-
If you get SSL working for http, then telnet over SSL might be an acceptably secure alternative to SSH for this context.
Alternatively, does the AJAX/web interface support "send G-code, get response" commands? If so it'd be easy to write a python terminal client that gave a telnet-like interface (albeit with client-side line editing).
-
A simple HTTP call to execute G-code and get the result in the response would be something I would like, too.
I wrote an iOS app and mounted an iPod touch on my printer to use as a touch screen interface (think PanelDue). I used Telnet because it seemed like he easiest way to get the response without polling the status. This obviously doesn't work with Duet WiFi, and I would much rather use HTTP.
-
@tomasf Is this not already possible through the console interface? Or am I misunderstanding?
As I see it, telnet (or ssh) would be useful to send the print via Gcode instead of the SD or USB direct from a slicer such as S3d but interactive Gcode is already possible on the web interface.
-
You can use the rr_gcode HTTP call to send gcode commands, and rr_reply to retrieve the response to the last gcode command that generated a response. Many gcode commands don't produce a response.
-
Yeah, it's that model of separating it into two commands that is the problem. It's not atomic; I can't be sure what command generated the response I get from rr_reply. It's "probably" the last one I sent, but it could also be something done by the web interface. And if I execute two M114 in a row and then do a rr_reply, it seems to contain the response of both. I've even seen the web interface itself get confused by what command the reply belongs to, presumably when the timing is right and something else happens between rr_gcode and rr_reply that affects the last response.
A single command to execute a G-code and get the response to that command and that command only would be great.
-
The problem is:
-
Most gcode commands don't generate any response at all, except when they are received over USB and Marlin emulation is in force. Ffor example G1 move commands.
-
Some commands can take an unbounded amount of time to execute. For example M116. So the model of sending a command and getting a response in the same HTTP request doesn't work, because it would result in browser timeouts.
It wouldn't be impossible for us to support Telnet, but it would have to be disabled by default because of the very serious security concerns. It may happen when the web server gets rewritten.
-
-
Does it make sense to have two HTTP connections - one that sends commands and one that simply collects all output from the printer? Sorry, I don't have my Duet yet, so I'm just going by what Marlin does (which is not a great model to emulate). But I do want to be able to "drive" the printer from software running on the host, whether by telnet or HTTP or carrier pigeon.
-
Yes we could add Telnet support and I will if there is enough demand (unless someone else does it first). However, Telnet is a very insecure protocol, not at all the sort of thing that I want running on my network, let alone on a WiFi connected device. One of the high priorities on my list is to improve the http security.
Just to add to the demand, I registered to say I'd love to have telnet.
My primary intention is actually to syslog interesting responses.The issue with http is that (at least in my current version on duet 0.8.5) sometimes I can't get g-code response reliably — I believe other browsers are eating it up, though never bothered to figure it out.
Of course I can also get all that over USB, but if I have telnet I can free up the raspberry that is connected to printers. (not sure what for, though).
And yes, geekiness also makes one feel comfortable having telnet
