Many devices have had a serial port for attaching a console of some sort, for low-level configuration/diagnostic work. While very simple to implement, serial ports have issues which don't need repeating.
An obvious alternative is to implement the "serial console" as a TELNET server. Conceptually this is trivial, not to mention well standardized and well understood. OTOH, this piles on a fair bit of complexity, and requires something akin to a full TCP/IP stack. And if you're going to do that, you might as well just go for a web-based admin, it's only going to be a bit more work.
OTOH, it's clear that a number of people have implemented a UDP-based protocol for handling the sort of things often done with a serial console attached to a device. This has a number of advantages - you can fake UPD over Ethernet with very little code, especially if you define away things like fragmentation and options. A simplified TELNET-ish protocol on top of that would be pretty simple, you just need some basic packet sequencing and acknowledgements. IOW, something with a relationship to TELNET sort of like TFTPs relationship to FTP.
OTOH, despite looking, I just don't see any standards for doing that sort of thing. Am I just missing it? Is there a defacto standard even if there's no RFC?
I suppose you have found nothing simply because doing telnet over UDP will take reinventing tcp. tcp is very well designed, I can't see how it can be simplified while retaining its basic functionality. I would expect there are super minimalistic tcp implementations which might more or less work and would do what you need but I don't really know what is out there, I have only written the tcp for dps which is not minimalistic.
I know of people who have implemented that on top of IP rather than UDP. They call it TCP. ;)
Just use a raw TCP connection. There's no need to implement the TELNET protocol at all. The Unix command line client will skip all the handshaking stuff if you use a non-standard port. Or you can use netcat. Or any number of terminal emulators or COM port redirectors that support raw TCP connections.
If you're on a local Ethernet segment, just use raw UDP. I've been using both those approaches for close to 20 years, and have never had any problems.
If you want something reliable that works over WANs, use TCP: it's the only way you're going to dependably make anything work through a firewall.
If you're going to assume local Ethernet, you can just use UDP.
--
Grant Edwards grant.b.edwards Yow! Gee, I feel kind of
at LIGHT in the head now,
gmail.com knowing I can't make my
satellite dish PAYMENTS!
Well, yes, but the point is that TCP is a fair chunk of code, and for this function it has to go in a spot where it's less than convenient to update. Hence the desire for maximum simplicity. I used TFTP as an example, since it solves a similar problem (and you could certatinly trivially implemented a TCP version of TFTP), with similar constraints.
Given how little TELNET actually does (or at least, needs to do), if you have TCP, there would be no really issue implementing that. Raw TCP is obviously an option, but again, the incremental cost to do actual TELNET is low. And as I said, if you have TCP, why not just do this with HTTP, and really make things convenient for people.
Yet what exactly is the protocol? How many characters can you put in a packet? Any sequencing or recovery? Acknowledgements? Checksums on or off? With UDP (and a bit of consideration at the protocol layer), you can even avoid any IP configuration requirements (at least on a single LAN) by doing everything with broadcasts.
I've simply never implemented anything with UDP that didn't take error handling into account - is the common practice just to assume that you will not lose/reorder/duplicate/mangle any packing so long as you're on a local segment? Again, TFTP addresses those issues, at least as they apply to its requirements.
Sure, no disagreement there. And no, operation over WANs is not a prime consideration, although it certainly wouldn't hurt if it could, even if the user had to deal with firewall issues, or set up a relay server of some sort. But the scope would be within a data-center, or perhaps campus (assuming at least real IP address assignment - without that, local LAN). Remember the idea here is to replace a serial console port.
Sure, doing TCP *well* requires pretty much re-inventing TCP. But the requirements here are much lower than that. Performance requirements are minimal, and operation over WANs (especially efficient operation over WANs) is not really an issue either. And it's already been done. A lot. I just want to know how. Again, TFTP is an example of a solution to a very similar problem.
I still don't see the problem: TCP has been around for decades and there are some tiny implementations, especially if you don't need multiple packets in the air at the same time etc. Why not just use one?
My experience with TFTP in early nineties was that on our network attempting to send file larger than 1MB will usually stall. We had several segments of thin Etehrent connected via a repeater and used cheap equipement. TCP run with quite resonable performance, but TFTP was essentially unusable. Apparently TFTP specification was extended to get better reliability (or maybe our implemetation dropped optional parts), but it seems that using raw UDP will give you _more_ reliability than I got from TFTP. More preciesely, IIRC both at Ehernet level and IP level you get a checksum for each packet. You are talkong about low performance, so presumably no need to throttle transmission. At low speed in local network there should be no problem with reordering packets. As my expample shows in practice TFTP was unable to retransmit missing packets. Together this means that acknowledgements buy you nothing => you are end up at raw UDP level.
Well, maybe modern TFTP is better, but IME TFTP did _not_ address the isssues.
I think you look at your problem from wrong point of view. Once you want decent capability for transmitting streams of data you end up with something very similar to TCP. So better question is: "what parts of typical TCP implementation can be safely skipped and which existing implementation has good support for doing so". Partial answer is: TCP implementation can be simplified quite a lot and still work reasonably well. Commer and Stevens in their 1994 book described "complete" implementation of Internet protocls, their code was simple but they tried to cover all required parts. They wrote that they needed about 3000 LOC for TCP (and slightly larger amount for mamdatory lower level parts). If you limit their implementation to TCP only (+ needed lower level parts) it will by probably 60% bigger than UDP only (again UDP + needed lower level parts). Compared to 1994 TCP was extended, but it seems safe to assume that even in modern network you should be able to use implementation having 6000 LOC (for TCP and lower layers, but exluding hardware handling). This 6000 LOC-s is likely to produce no more than 8-16 KB of machine code. RAM overhead is of order few hundreds bytes per connection plus needed buffering (likely few kilobytes). If you want reliable transmission you need buffering (to be able to retransmit) so extra requirements seem to be quite modest. And if you have enough free RAM you probly also have enough program space (typical MCU-s seem to have much more program space than RAM). Of course, you may use tiny MCU with external Ethernet (or Wifi) chip providing buffering, but if you add such a chip to existing system maybe it is better to add a "communication processor" that handles all network aspects (ESP8266 will do this for Wifi).
The TCP/IP stacks that I know about seem to be larger than estimate I gave above. But they have options to omit parts, so maybe you can trim them down.
Significant part of complexity of TCP comes from handling long streams. If you can live with small HTTP pages than there is very small implementation at tuxgraphics.org. The implementation is quite small but they do it via limiting HTTP page to a single Ethernet packet. This implementation violates several requirements of TCP/IP, but seem to work quite well in practice.
By the time you do "packet sequencing and acknowledgements" for both target and host side, test it, revisit the bad protocol design decisions, and then re-implement it for both sides you've spent more time than you would have just doing a simple TCP implementation.
And in the end you've got something that's non-standard, non-portable, probably still doesn't work right, and for which Wireshark doesn't have a packet dissector.
Don't underestimate the importance of that last one.
What features of TELNET do you need?
In my experinece the incremental value of Telnet is negative, since various Telnet clients behave it vastly different and bizarre ways.
YMMV.
OK.
Um... UDP.
UDP says 65536 bytes per datagram. UDP will fragment that and reassemble it. If you want to do a stripped-down UDP iplimentation, limit it to about 1200.
Nope.
Nope.
For a local Ethernte segment, you let the MAC layer worry about that.
Some IP stacks won't receive UDP broadcast packets with a non-reachable source IP.
Unless your Ethernet segment is pretty heavily loaded, I find you can ignore all that.
If you can't, then you need the equivalent of TCP.
Not if this is limited, as is (basic) TFTP, to a single outstanding packet (in each direction). A simple sequence number is all you need, and the ability to retransmit one packet, plus a timer for detecting missing acks. I've done all that before, more than once.
While I've never written a decode for Wireshark, I've written several for other packet monitors, I suspect I'd actually enjoy that little task. ;-) OTOH, given the simplicity of the protocol, it's value would be moderate.
None really. The idea would be to assume a simple bidirectional stream to a VT-100 (or heck, even a TTY in many cases). Just enough of TELNET to allow standard clients to be used. If this were a custom protocol, I'd at least have a version exchange somewhere at session setup.
Well, most of them at least manage a basic VT-100 connection, and most of their (TELNET) responses, odd or not, could be mostly ignored in this implementation. I've been reconsidering the notion of a raw-TCP stream support, this appears to be a rather more common option in TELNET clients than I had expected. Still doing a minimalist TELNETD would not be much work, and if it significantly improved compatibility, would probably be worth it.
Well, if that's what people have been doing, then I think the answer to my original question is: no, nothing usable is standard(-ish). I don't think any usable UDP-based protocol can avoid some error handling (unless it's a protocol for something where data loss is tolerable - media streams, for example). Which doesn't mean that for some protocols it's not utterly trivial: Didn't get your DNS response? Send the query again.
I suspect we'll probably end up with a proper TCP, the advantages of not having to deal with the client are significant, despite the considerable extra complexity on the device.
Remember that the starting point here is little more than the equivalent of fgets() or puts() support to a serial port (hardcoded
9600-N-8-1, no flow control). You can do that (less any actual command implemented) in under 500 LOCs. The *fancy* version assumes a VT-100. Going the TCP route with the Ethernet chip driver, IP, UDP, DHCP, ICMP, and TCP, and you're talking well over 10KLOCs, with over half that being in TCP.
The whole what-do-you-do-if-you-don't-have-an-IP-config thing is a PITA for IPv4. Hope for DHCP, then try a link-local address, then try a fixed local address, then... But that's an issue for any implementation, but UDP offers some additional possibilities (like broadcasts). But nothing works everywhere.
That may well be the way we go, but given that more than a few UPD-only implementations have been done, I was trying to determine if a lighter-weight alternative was feasible.
Certainly bad TFTP implementations exist, but there's really nothing in the protocol that should permit behavior as bad as you describe.
All at least roughly true. As an aside, though, the LOC count is wrong in the 1994 edition. The pie chart is correct, but they didn't update the LOCs from the 1991 edition, despite adding OSPF and some other stuff to the implementation. So from the 1991 edition, you had
26% of the 15KLOC base in TCP (or ~4K, which is about the right number for their implementation), not 20% of 15KLOCs as in the 1994 edition (where the count should actually be been ~19KLOCs). The 4KLOCs in their SNMP and RIP implementations are omitable.
Yes, in my experience they've all been bigger than that.
Not really an option, one packet is just going to be too small for HTTP.
If you just need a primitive command line debugger for a small device with ethernet port but no serial port, the simplest would be to hack the printf() in the small device with a routine that sends a raw Ethernet package or an UDP packet.
On the bigger client machine, you would need a routine that reads a command line (e.g. to facilitate command line editing) and when the user hits the CR key, a raw ethernet or UDP frame is sent and processed by the small server.
An even simpler case, setup Wireshark capture filter to listen for the MAC address of the small device. In this case, the only thing that the "telnet" needs to do is to read a command line and send it out as a raw ethernet or UDP frame.
If there is only one connection point, raw Ethernet with MAC addresses should be enough, but if multiple command points are needed in the future, including the IP header with port numbers will help, but then you would have to implement the ARP o the small device.
The OP was complaining about how much work it would be to implement TCP, so I was comparing that to what he was proposing. Using an open-source TCP/IP implementation makes the comparison come out even more in favor of TCP.
I've not used uIP, but it's by Adam Dunkels so it gets a few points right away in favor. I've used his protothreads library for stackless multitasking on a uController with only a couple hundred bytes of RAM, and it was very cool, very well done, and very useful.
--
Grant Edwards grant.b.edwards Yow! Why are these athletic
at shoe salesmen following
gmail.com me??
A bit??? I think you left a "quite" out. :) If the target is Linux, then it's less trouble, but it's still somewhat involved.
Easily done.
I am not sure you even really need that. SNMP doesn't need it; it has the "as if simultaneous" rule; when multiple PDus are used to define an essentially atomic operation, they are to be treated as if they all got there the same time. It's not assumed that the sender sent them in order or without some other operation concurrently.
It is worth defining use cases carefully for such a protocol to keep half-done things and race type[1] conditions to a minimum.
[1] unless you wish to assume only one session at a time.
Then again, there's nothing wrong with sequence numbers, but it's sort of non-Telnet-ish if you do that.
There isn't one that I know of. But it is essentially quite easy.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.