Re: UDP Terminal Protocol

From	Don Y <blockedofcourse@foo.invalid>
Newsgroups	comp.arch.embedded
Subject	Re: UDP Terminal Protocol
Date	2016-12-14 15:09 -0700
Organization	A noiseless patient Spider
Message-ID	<o2sfro$psh$1@dont-email.me> (permalink)
References	<7phv4cd0dickoubm7k7rud6or7vtnft8rb@4ax.com> <o2pji6$j7r$1@dont-email.me> <6m735c5dsjojm1b37rlmk8tt2dadneijbj@4ax.com>

Show all headers | View raw

On 12/14/2016 1:03 PM, Robert Wessel wrote:
> On Tue, 13 Dec 2016 12:53:57 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>>> 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.
>
> Not really sure I'd agree with that, but both are pretty simple.  If I
> had TCP, doing either TELNET or RLOGIN (or HTTP) is not much of an
> issue.  OTOH, there doesn't really seem to be much advantage for doing
> RLOGIN over TELNET.

Just to make sure there's no misunderstanding, RLOGIN runs over TCP;
you'd use it in lieu of TELNET.  (a full TELNET implementation is
many thousands of lines of code -- much of which you probably won't
need if you just want to emulate a serial port)

>> What criteria do you place on the operating environment?  E.g., you
>> can't run a bare "serial port" 1000km.
>
> No, but one would hope to do something with a bit more range than a
> serial port (which is what's there now), and a bit more convenient
> infrastructure-wise.  Design "range" should be something on the
> data-center to campus scale.  One of the prime considerations is the
> ability to manage many devices without the complexity of attaching to
> many serial ports scattered around the data center.

Once you "leave the room", things typically get complicated (unless
you're willing to live with a 100m cable limitation).  And, once you
start trying to talk to existing fabric, you have even less leeway
in terms of the corners you can cut (e.g., what happens if some
host tries to ping your node?  open an FTP connection?  etc -- even
if wrong in attempting to do so).

Many years ago (10+) I put together a proposal for a low cost "console server"
(essentially a one-port terminal server) to facilitate LOM in a datacenter
environment.  At the time, I could enhance security and cut cost by
bastardizing the network protocols with the caveat:  all of these devices will
reside on an isolated internet (so they didn't have to contend with the
variety of traffic they might encounter on a "live" internet).

Nowadays, SoC's have far more resources so even a complete stack isn't
going to break the bank (unless you're *really* scraping the bottom
of the cost/commodity barrel).

>>  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?
>
> I don't really want a special device, although a PC with special

The "PC" was the intent of my reference  :>  The point being, it's not
an OTS solution (you still need to "develop" that end of the link).

> software is reasonable, but at worst case you'd want that PC to need
> to be no closer than somewhere on the local LAN (data center or
> campus, as mentioned above, would be better).  If you didn't mind a
> special device, there are RS-232-to-TELNET devices you could just plug
> into the serial port, and define the whole problem away.  As to flow
> control and whatnot, those issue should be kept to a minimum (again
> TFTP is a parallel), but since this has been done before, I'm trying
> to figure out if there's existing practice to piggyback on.  If, for
> example, there's a semi-standard way to do this, there are likely
> terminal emulators that already support that.

There have been lots of attempts at making "console servers" (my
reference above).  HP had a "Secure Web Console" that presented
a "terminal emulator" in a web browser window that was tethered
to the remote device's serial port.

[It was a poorly designed product, though -- particularly the
laughable "secure" aspect of it!  :> ]

You can buy single port terminal servers in a package not
much larger than a DB25 backshell (the proposal I outlined above
called for a DB9 backshell package as most servers now have 9 pin
serial ports so you don't have room for a "box" behind the server)

> The big advantage to going "whole hog" and doing TCP and TELNET (or
> TCP and HTTP), is that you open this up to the whole Internet, and an
> untold number of existing clients for any conceivable platform.

As Devil's Advocate, I'd point out that you now present a larger
attack surface and a (potentially) bigger adversary pool; one
thing with which a simple serial port didn't have to contend!

> Physically, the idea would be to replace the serial port with an
> Ethernet port.  It would be nice to be able to still connect without
> any network infrastructure at all (beyond, possibly, a crossover
> Ethernet cable).

It might be interesting to consider putting serial port *and* ethernet
on the same connector (I'd have to consider the hardware consequences
to see if there's a "cheap" way of doing so).

>> 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).
>
> The model under consideration is a replacement of a serial console
> assumed to be a VT-100 compatible device.  I don't think a hack like
> you're suggesting is viable.  At that point we're talking about custom
> software on both ends, so a "proper" TELNET-ish* protocol over UDP
> would be simpler.  Developing such a (new) protocol is no problem.

If you were willing to make the "special device" a PC, then this
just changes the nature of the software running in the PC (given
that the "device end" is already negotiable).

I offer it only because I've frequently designed "screen oriented"
user interfaces (think: menu/dialog system atop curses(1)) so the
UI is always a ~2KW buffer in the device's memory that just gets
painted (via ANSI escape sequences) onto the hardware TTY.  Pushing
those 4KB out through a set of ~8 UDP packets (on demand any time
user asks for the screen to be repainted) would be a piece of cake;
much simpler than the curses stack residing in the device -- or the
ANSI emulator in the PC!

[The Sun Ray operated in a similar fashion; and, AFAICT, the Pano
cubes (no CPU -- entirely FPGA based) use a similar approach to
"painting a screen"]

> *And let's not get too hung up on the specifics of TELNET here - some
> bits of handshake information probably need to be exchanged at the top
> of the session, and then it's just a packaging of the bi-directional
> serial stream.

If you want to interoperate with other devices, you may have to implement
bits of the protocol that you'd hoped you could elide.  E.g., MS's
TELNET client is a PITA for me to use, here -- so I install third-party
TELNET clients that "work".

>> 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.
>
> Sure: I'd like to pare-back the network stack by not implementing TCP.
> ;-)  Limited UDP-only on top of Ethernet is pretty trivial.

But, even with TCP, there are economies available.  If you try to
cheap out and port an existing stack (FOSS), you will typically end
up with more resources (and features) than you might otherwise need.

IMO, the biggest downside is you'll typically insulate yourself from
the inner workings of the stack and, thus, not be aware of the sorts of
exploits that lie in wait.  Or, the costs (space/performance) that you
are bearing.

Thereafter, you have to track new releases of that codebase to see
if/when to fold them into one of your "updates".  This could result in
your taking on additional functionality/resource requirements that
you might not want.

OTOH, if you "take ownership" of such a codebase (i.e., start tweeking
it to *fit* your needs), then you're still stuck watching the releases
and now have to merge "pertinent" changes into your codebase.

[I.e., you quickly start to feel like the dog's *tail*!]

If you haven't, already, Comer's XINU (vol2) is a lightweight introduction
to the stacks; followed by his _Internetworking with TCP/IP_ series.
With those behind you, Stevens' _TCP/IP Illustrated_ is by far the best
reference.

[Though Stevens' texts tend to describe more efficient (from the
standpoint of performance) implementations; Comer's tend to be much
easier to visualize -- more *discrete* layers (and, thus, less
efficient)]

And, watch the CERT advisories to see how profoundly varied attacks
on stacks can be, in practice!

Thread

UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-13 04:23 -0600
  Re: UDP Terminal Protocol Dimiter_Popoff <dp@tgi-sci.com> - 2016-12-13 17:10 +0200
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 13:33 -0600
  Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-13 15:16 +0000
    Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-13 18:51 +0200
      Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-13 21:13 +0000
        Re: UDP Terminal Protocol Clifford Heath <no.spam@please.net> - 2016-12-14 09:05 +1100
      Re: UDP Terminal Protocol Rob Gaddi <rgaddi@highlandtechnology.invalid> - 2016-12-13 13:23 -0800
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 13:28 -0600
      Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-14 15:29 -0700
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:34 -0600
          Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 01:10 -0700
        Re: UDP Terminal Protocol Les Cargill <lcargill99@comcast.com> - 2016-12-15 21:52 -0600
          Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 22:00 -0700
      Re: UDP Terminal Protocol Paul Rubin <no.email@nospam.invalid> - 2016-12-14 15:22 -0800
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:00 -0600
      Re: UDP Terminal Protocol antispam@math.uni.wroc.pl - 2016-12-15 01:49 +0000
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:17 -0600
      Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-15 02:06 +0000
        Re: UDP Terminal Protocol Paul Rubin <no.email@nospam.invalid> - 2016-12-14 21:09 -0800
          Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-15 17:38 +0000
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 23:58 -0600
      Re: UDP Terminal Protocol Les Cargill <lcargill99@comcast.com> - 2016-12-15 21:49 -0600
      Re: UDP Terminal Protocol Morten Reistad <first@last.name.invalid> - 2016-12-24 16:10 +0100
        Re: UDP Terminal Protocol Grant Edwards <invalid@invalid.invalid> - 2016-12-24 18:53 +0000
          Re: UDP Terminal Protocol Theo Markettos <theom+news@chiark.greenend.org.uk> - 2016-12-25 13:45 +0000
            Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-25 11:44 -0700
  Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-13 12:53 -0700
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-14 14:03 -0600
      Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-14 15:09 -0700
        Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-15 00:50 -0600
          Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 11:01 -0700
        Re: UDP Terminal Protocol Morten Reistad <first@last.name.invalid> - 2017-01-15 16:08 +0100
      Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-15 15:08 +0200
  Re: UDP Terminal Protocol wzab01@gmail.com - 2016-12-14 13:16 -0800
  Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-15 12:56 +0200
    Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-15 11:06 -0700
      Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-26 16:34 -0600
        Re: UDP Terminal Protocol upsidedown@downunder.com - 2016-12-27 07:45 +0200
        Re: UDP Terminal Protocol Don Y <blockedofcourse@foo.invalid> - 2016-12-26 23:00 -0700
          Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2017-01-03 18:48 -0600
  Re: UDP Terminal Protocol Les Cargill <lcargill99@comcast.com> - 2016-12-15 21:42 -0600
    Re: UDP Terminal Protocol Robert Wessel <robertwessel2@yahoo.com> - 2016-12-26 17:21 -0600

csiph-web