Telnet support
-
The short answer: I'm a geek. Geeks use telnet. And because of that I can control my current printers from my Commodore 64 if I wanted to, or when ssh'ed into one of my Linux box from anywhere in the world. No farting around with clunky web browsers required. And I'd also wager a bet many RepRap builders are just as geeky as I am.
But in all seriousness, while the web based solution is a fantastic user interface for many folks, I prefer to keep a telnet session open to do simple tasks that I can type faster than click around in a web browser. So for example I can use the telnet session to issue G28 to re-home, G0 Z0 to drop the nozzle down to the bed, jog around a bit to set the perfect Z0 offset, and start my print job–faster than waiting for the Duet Web to even load from my Duet 0.6.
I'm your typical grumpy old power user-so when marketing folks start taking my familiar and efficient CLI away...I get even grumpier.
GUI's and web interfaces are great, but not at the expense of loosing something fundamental like a reliable CLI console. To me it would be the same as taking away the rear windshield in a new car--sure you can use the backup camera but why would you do that when you've got a perfectly good pair of eyes and a brain that can judge distances far better than any fancy LCD display.
Dieter
-
I agree to some of the sentiment here. I feel that the products should not change so abruptly as they progress. Getting used to the duet0.8.5 workflow, and planning a set of printers and workflow around it, made it a shock to see some of the functionality changes in the Wifi version.
-
Funny, not two minutes ago I was just reading your comments in the camera discussion and chuckling to myself about how you sound very similar to me.
@bot:
I agree to some of the sentiment here. I feel that the products should not change so abruptly as they progress. Getting used to the duet0.8.5 workflow, and planning a set of printers and workflow around it, made it a shock to see some of the functionality changes in the Wifi version.
-
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
