Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #25559 > unrolled thread

UDP Terminal Protocol

Back to article view | Back to comp.arch.embedded

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#25586

On 2016-12-15, Paul Rubin <no.email@nospam.invalid> wrote:
> Grant Edwards <invalid@invalid.invalid> writes:
>> you've spent more time than you would have just doing a simple TCP
>> implementation.
>
> I still don't understand why the OP would want to "do" (i.e. write) a
> simple TCP implementation instead of downloading one.

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.

> There are lots,
> e.g.:
>
> https://en.wikipedia.org/wiki/UIP_(micro_IP)

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

[toc] | [prev] | [next] | [standalone]

#25578

On Thu, 15 Dec 2016 02:06:18 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> wrote:

>On 2016-12-14, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> 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,
>
>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.


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.


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


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.


>>>> IOW, something with a relationship to TELNET sort of like TFTPs
>>>> relationship to FTP.
>
>What features of TELNET do you need?


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.


>>>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.
>
>In my experinece the incremental value of Telnet is negative, since
>various Telnet clients behave it vastly different and bizarre ways.
>
>YMMV.


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.


>> And as I said, if you have TCP, why not just do this with HTTP, and
>> really make things convenient for people.
>
>OK.
>
>>>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?  
>
>Um... UDP.
>
>> How many characters can you put in a packet?
>
>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.
>
>> Any sequencing or recovery?
>
>Nope.
>
>> Acknowledgements?
>
>Nope.
>
>> Checksums on or off?
>
>For a local Ethernte segment, you let the MAC layer worry about that.


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.


>> 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.
>
>Some IP stacks won't receive UDP broadcast packets with a
>non-reachable source IP.


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.


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

[toc] | [prev] | [next] | [standalone]

#25590

Robert Wessel wrote:
> On Tue, 13 Dec 2016 15:16:12 +0000 (UTC), Grant Edwards
> <invalid@invalid.invalid> wrote:
<snip>
>
> 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.
>
>

If you are using UDP on a local segment, you're reasonably safe assuming 
things are in order and not fragmented unless you try to
push the envelope with large PDUs.

Over a router of unknown configuration? Not so much.

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

Serial ports don't change the order of arrival or fragment :)

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


-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#25626

In article <qs535ctbk361kav29rjd236dat22mo199e@4ax.com>,
Robert Wessel  <robertwessel2@yahoo.com> wrote:
>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.

A rudimentary "simple-tcp" that is not quite compliant with
TCP but will interoperate with one that is is not much code.
You will have to handle a connection or maybe a handful, but not
very many. You will have to do retransmissions, but you can back
off to a constant, semi-high value (like 6 seconds) on the second
attempt. You can deny all options, and stay with a small window
of a few k, and send 512 bytes or less.

That should reduce the requirements to a few hundred lines of
code beyond implementing UDP.

You can also have a very rudimentary telnet negotiation, basically
enforcing a standard set of options and accepting nothing else.

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

You probably have to have some default IP address, which you can
change. Making a simple udp one-shot protocol to set such options
should be easy.

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

A "simple-TCP" will handle this, and you could make a udp simple
config-setter like the ones digium does for the iaxys should be
an afternoon's work.

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

You will be amazed on how much chatter, duplications and other
stuff I have found on ethernets.

-- mrr

[toc] | [prev] | [next] | [standalone]

#25628

On 2016-12-24, Morten Reistad <first@last.name.invalid> wrote:

> You can also have a very rudimentary telnet negotiation, basically
> enforcing a standard set of options and accepting nothing else.

That turns out to be surprisingly difficult.  It's not a lot of code,
but no two clients behave the same, and the first time you trie a new
client, you find a new problem.

>>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.
>
> You probably have to have some default IP address, which you can
> change. Making a simple udp one-shot protocol to set such options
> should be easy.

One clever method for establishing an initial IP address that I've
seen is that the embedded device watches for unicast IP packets sent
to its MAC address.  When it sees one, it temporarily adopts whatever
destination IP address was in the packet. That way, to initially
configure the device's IP, all you have to do is add an entry to your
host's ARP cache with the desired IP address and then ping that IP
address. IIRC, the device in question only did this if the device was
at factory defaults.

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#25632

Grant Edwards <invalid@invalid.invalid> wrote:
> One clever method for establishing an initial IP address that I've
> seen is that the embedded device watches for unicast IP packets sent
> to its MAC address.  When it sees one, it temporarily adopts whatever
> destination IP address was in the packet. That way, to initially
> configure the device's IP, all you have to do is add an entry to your
> host's ARP cache with the desired IP address and then ping that IP
> address. IIRC, the device in question only did this if the device was
> at factory defaults.

Or you could just use IPv6: router broadcasts Router Advertisements
containing the local network prefix.  Client picks that up, appends its MAC
address, it now has its IP.  Everyone else can work out the IP too.
This is not special 'factory defaults' magic, it's how IPv6 works all the
time.

Theo

[toc] | [prev] | [next] | [standalone]

#25633

On 12/25/2016 6:45 AM, Theo Markettos wrote:
> Grant Edwards <invalid@invalid.invalid> wrote:
>> One clever method for establishing an initial IP address that I've
>> seen is that the embedded device watches for unicast IP packets sent
>> to its MAC address.  When it sees one, it temporarily adopts whatever
>> destination IP address was in the packet. That way, to initially
>> configure the device's IP, all you have to do is add an entry to your
>> host's ARP cache with the desired IP address and then ping that IP
>> address. IIRC, the device in question only did this if the device was
>> at factory defaults.
>
> Or you could just use IPv6: router broadcasts Router Advertisements
> containing the local network prefix.  Client picks that up, appends its MAC
> address, it now has its IP.  Everyone else can work out the IP too.
> This is not special 'factory defaults' magic, it's how IPv6 works all the
> time.

[N.B. IPv6 is a costlier stack]

The problem with all discovery/configuration services is they
can be spoofed by a malicious host ("server") introduced on the
local network.  And, unless you have an IDS in place and/or
vigilant staff monitoring ALL log files for "unusual" but
TRANSIENT (!) error messages ("address already in use", etc.),
you're unlikely to know a service has been hijacked to compromise
one or more hosts (and wonder the use for which THOSE hosts are
now targeting).

[toc] | [prev] | [next] | [standalone]

#25563

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.

[toc] | [prev] | [next] | [standalone]

#25570

On Tue, 13 Dec 2016 12:53:57 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

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


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.


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


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

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.

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



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


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


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

[toc] | [prev] | [next] | [standalone]

#25572

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!

[toc] | [prev] | [next] | [standalone]

#25582

On Wed, 14 Dec 2016 15:09:13 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

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


It somewhat depends on the connector.  RS-232 and Ethernet signals
won't damage each other's ports, so some incorrect connections are not
harmful.  If you stuck with a standard RJ-45, and 10/100 Ethernet, you
have four unused pins, which is likely enough for the RS-232 side. You
could then use a standard twisted pair Ethernet patch cable for the
Ethernet connection, and a special cable for the serial side. While
the RS-232 pins would be connected to the far device (typically the
switch) in the Ethernet scenario, the extra pins should not get used,
since the device won't negotiate anything faster than 100Mb, so the
remote side should ignore anything it sees on the other four wires.

A problem with that is that usually the inexpensive way to get the
RJ-45 connector onto your device is to get a jack that integrates the
magnetics.  And those tend not to make the extra pins available.  So
you'd probably have to use discrete magnetics.

If you were willing to go to a less standard connector (perhaps an
RJ-50 - aka 10P10C), you'd have enough signals for handshaking on the
serial port as well, but you'd need custom cables for both connection
types.  And of course you'd need separate magnetics.

[toc] | [prev] | [next] | [standalone]

#25587

On 12/14/2016 11:50 PM, Robert Wessel wrote:
> On Wed, 14 Dec 2016 15:09:13 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>>> 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).
>
> It somewhat depends on the connector.  RS-232 and Ethernet signals
> won't damage each other's ports, so some incorrect connections are not
> harmful.  If you stuck with a standard RJ-45, and 10/100 Ethernet, you
> have four unused pins, which is likely enough for the RS-232 side. You

I was thinking more in terms of *sharing* conductors between interfaces.
See my previous '"On-line" 100BaseTX hardware diagnostics' post as
its along the same lines -- using a second I/F to leverage the existing
*wiring* of the first in the event of a failure of the first.  I.e.,
ethernet has failed but can I still exploit the existing WIRING
to talk to other nodes -- albeit at a crippled rate.

The flip side of this is allowing either interface to appear on
a single connector, moving the "user's choice" into the
cable with which he connects to your device (one terminated in
a DB9/25, the other in an RJ45)

> could then use a standard twisted pair Ethernet patch cable for the
> Ethernet connection, and a special cable for the serial side. While
> the RS-232 pins would be connected to the far device (typically the
> switch) in the Ethernet scenario, the extra pins should not get used,
> since the device won't negotiate anything faster than 100Mb, so the
> remote side should ignore anything it sees on the other four wires.
>
> A problem with that is that usually the inexpensive way to get the
> RJ-45 connector onto your device is to get a jack that integrates the
> magnetics.  And those tend not to make the extra pins available.  So
> you'd probably have to use discrete magnetics.
>
> If you were willing to go to a less standard connector (perhaps an
> RJ-50 - aka 10P10C), you'd have enough signals for handshaking on the
> serial port as well, but you'd need custom cables for both connection
> types.  And of course you'd need separate magnetics.
>

[toc] | [prev] | [next] | [standalone]

#25712

In article <o2sfro$psh$1@dont-email.me>,
Don Y  <blockedofcourse@foo.invalid> wrote:
>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)

Minimal telnet is just sending a handful of bytes as soon as
the session is established, and then just use the raw tcp. You
would want to turn off the default line-mode, and set character
mode. That is just one small printf/echo/print/whatever as soon
as you have the session set up.

You would need a retransmit timer, but it can be _very_simple, e.g.
6 seconds if you haven't seen an ack. You need to handle four
window pointers, one for how far we have sent and one for how
far we have received, for both transmit and receive. They are
set in the initial syn-ack-synack dialogue. You would need to
implement fin-finack-fin2 to terminate the session as well.

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

You would employ such a server behind one or more firewalls, I am sure.
Just filter it from anyone that doesn't belong there.

This is for console access, not any big user community.

-- mrr

[toc] | [prev] | [next] | [standalone]

#25585

On Wed, 14 Dec 2016 14:03:59 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:


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

I guess that you are aiming of some single chip microcontrollers with
internal RAM only but with on-chip Ethernet interface. 

Of course, you will need two 1500 byte buffers for the Ethernet Rx and
Tx frames,  Raw Ethernet will need only marginally more and the UDP
implementation doesn't meed much more for multiple port number
support.

[toc] | [prev] | [next] | [standalone]

#25571

W dniu wtorek, 13 grudnia 2016 11:22:52 UTC+1 użytkownik robert...@yahoo.com napisał:
> 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?

If you are interested in control and diagnosis of FPGA based systems, then you may take a look at IPbus: https://svnweb.cern.ch/trac/cactus
However, as this is comp.arch.embedded, not comp.arch.fpga, that probably won't help you too much.

Regards,
Wojtek

[toc] | [prev] | [next] | [standalone]

#25584

On Tue, 13 Dec 2016 04:23:16 -0600, Robert Wessel
<robertwessel2@yahoo.com> 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.

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.

[toc] | [prev] | [next] | [standalone]

#25588

On 12/15/2016 3:56 AM, upsidedown@downunder.com wrote:
> On Tue, 13 Dec 2016 04:23:16 -0600, Robert Wessel
> <robertwessel2@yahoo.com> 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.
>
> 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.

My read of the OP's comments was that he wanted a means of talking with
the "command/control console" of his device, remotely, using network
fabric instead of a dedicated "serial" link.

E.g., in a data center environment, this would be used for LOM -- in
lieu of a "display and keyboard".

Old server farms were littered with KVM's and rack-mounted "terminals"
(fold-away LCD monitor plus keyboard wired to the KVM).  But, that required
users to be present in the cold aisle to "manage" the servers.

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

[toc] | [prev] | [next] | [standalone]

#25634

On Thu, 15 Dec 2016 11:06:19 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>My read of the OP's comments was that he wanted a means of talking with
>the "command/control console" of his device, remotely, using network
>fabric instead of a dedicated "serial" link.
>
>E.g., in a data center environment, this would be used for LOM -- in
>lieu of a "display and keyboard".


While it's moot at this point, I need to support more low-level stuff
than an operational console.  Think BIOS setup screens.

[toc] | [prev] | [next] | [standalone]

#25636

On Mon, 26 Dec 2016 16:34:08 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:

>On Thu, 15 Dec 2016 11:06:19 -0700, Don Y
><blockedofcourse@foo.invalid> wrote:
>
>>My read of the OP's comments was that he wanted a means of talking with
>>the "command/control console" of his device, remotely, using network
>>fabric instead of a dedicated "serial" link.
>>
>>E.g., in a data center environment, this would be used for LOM -- in
>>lieu of a "display and keyboard".
>
>
>While it's moot at this point, I need to support more low-level stuff
>than an operational console.  Think BIOS setup screens.

This is a completely new requirement.

No way you could handle this with UDP or even TCP..

You will need some remote KVM system (such as Black Box) which
transfer the keyboard, mouse signals as well as the (VGA) scan raster
to a remote site.

If the data center device can be controlled solely over a serial link,
just install an ethernet to serial converter close to the device to be
controlled and connect to that converter using standard Telnet.

[toc] | [prev] | [next] | [standalone]

#25637

On 12/26/2016 3:34 PM, Robert Wessel wrote:
> On Thu, 15 Dec 2016 11:06:19 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> My read of the OP's comments was that he wanted a means of talking with
>> the "command/control console" of his device, remotely, using network
>> fabric instead of a dedicated "serial" link.
>>
>> E.g., in a data center environment, this would be used for LOM -- in
>> lieu of a "display and keyboard".
>
> While it's moot at this point, I need to support more low-level stuff
> than an operational console.  Think BIOS setup screens.

That was the sort of application that inspired my "screen" comment:
    "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)."

But, your other requirements suggest you *also* need a stream-oriented
interface.

While you can layer a *screen* oriented interface atop a stream, the
opposite is a bit tougher.

When you also throw in the need to transit network segments, it seems
the only practical approach is to implement a pared down TCP and
RLOGIN (or TELNET, depending on the clients you have available).

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web