UDP Terminal Protocol

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?

On 13.12.2016 г. 12:23, Robert Wessel wrote:
> 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.

Dimiter

------------------------------------------------------
Dimiter Popoff, TGI             http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/

On 2016-12-13, Robert Wessel <robertwessel2@yahoo.com> wrote:

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

I know of people who have implemented that on top of IP rather than
UDP.  They call it TCP. ;)

> IOW, something with a relationship to TELNET sort of like TFTPs
> relationship to FTP.

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.

> 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?

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!

On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

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

Thanks for the pointer to netcat.

I tried to find out , does it also support raw ethernet frames (with
MAC addressing) so that it could work without IP-headers and ARP ?

On 12/13/2016 3:23 AM, Robert Wessel wrote:
> 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?

RLOGIN is much lighter-weight than TELNET (YMMV).  But, as with TELNET,
runs atop TCP.

What criteria do you place on the operating environment?  E.g., you
can't run a bare "serial port" 1000km.  Are you just trying to exploit
an existing connector (RJ45) for a secondary purpose with a LOCAL
"console"?  I.e., do you need flow control, fragmentation/packet reassembly,
routing, etc.?  Or, will you just slap some "special device" on the
wire "in close proximity to" the device in question?

Does the interface have to be interactive?  E.g., you could leverage
something akin to TFTP to push a "screen" of data to/from a console
device (treat the screen as a "form" that is filled in instead of
as a STREAM).

You can also implement a much pared-back network stack by putting
other constraints on how you plan to USE that stack (limit number
of open sockets, window size, etc.)  E.g., my devices are intended to
talk to specific *other* devices so I don't have to maintain ARP
caches, multiple endpoints, etc.

On 2016-12-13, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
><invalid@invalid.invalid> wrote:
>
>>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.
>
> Thanks for the pointer to netcat.
>
> I tried to find out , does it also support raw ethernet frames (with
> MAC addressing) so that it could work without IP-headers and ARP ?

I don't think so.

It's trivial to write something (on Linux) in Python that bascially
does what "netcat" does but in MAC mode.  On Windows, it's way more
work...

-- 
Grant Edwards               grant.b.edwards        Yow! Will it improve my
                                  at               CASH FLOW?
                              gmail.com            

On 12/13/2016 08:51 AM, upsidedown@downunder.com wrote:
> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
> <invalid@invalid.invalid> wrote:
>
>> 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.
>
> Thanks for the pointer to netcat.
>
> I tried to find out , does it also support raw ethernet frames (with
> MAC addressing) so that it could work without IP-headers and ARP ?
>

There's a Linux program called socat that will do that type of thing. 
It's not installed by default but should be easy to get.

On 14/12/16 08:13, Grant Edwards wrote:
> On 2016-12-13, upsidedown@downunder.com <upsidedown@downunder.com> wrote:
>> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
>> <invalid@invalid.invalid> wrote:
>>
>>> 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.
>>
>> Thanks for the pointer to netcat.
>>
>> I tried to find out , does it also support raw ethernet frames (with
>> MAC addressing) so that it could work without IP-headers and ARP ?
>
> I don't think so.
>
> It's trivial to write something (on Linux) in Python that bascially
> does what "netcat" does but in MAC mode.  On Windows, it's way more
> work...
>

libpcap has pcap_sendpacket, which I think does what you want,
including on Windoze

On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2016-12-13, Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>> 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.
>
>I know of people who have implemented that on top of IP rather than
>UDP.  They call it TCP. ;)


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.


>> IOW, something with a relationship to TELNET sort of like TFTPs
>> relationship to FTP.
>
>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.


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.


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


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.


>> 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?
>
>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.


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.


>If you're going to assume local Ethernet, you can just use UDP.

On Tue, 13 Dec 2016 17:10:44 +0200, Dimiter_Popoff <dp@tgi-sci.com>
wrote:

>On 13.12.2016 ?. 12:23, Robert Wessel wrote:
>> 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.


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.