Serial (rs232 etc.) to IP

Hi,

Could anyone lend some light into which protocol or technique is used
to actually send I/O from a legacy serial port device onto a TCP/IP
network?  I see there are many products out there, but none of the
product sites describe the actual protocol used on the IP network side.
 An RFC search also came up with nothing, though I could have missed it
as well...  I know that on the client side (such as a Windblows
machine) the IP packets can also then be accessed as a COM port from
the software side...

TIA,
-D

packer44@hotmail.com wrote:

> Could anyone lend some light into which protocol or technique is used
>  to actually send I/O from a legacy serial port device onto a TCP/IP 
> network?  I see there are many products out there, but none of the 
> product sites describe the actual protocol used on the IP network
> side. An RFC search also came up with nothing, though I could have
> missed it as well...  I know that on the client side (such as a
> Windblows machine) the IP packets can also then be accessed as a COM
> port from the software side...

AFAIK there is no 'standard' for the transport of serial traffic over an 
IP network. Each case is application-specific. (There may be a few 
'system management' standards - I see 'SoL' bandied about - but nothing 
generic as far as I can tell).

Usually a generic solution would 'tunnel' serial data over raw UDP/TCP 
packets via a proprietory driver, optionally with a PC API for accessing 
the serial data at the other end of the network connection. For example, 
the API/driver would abstract a virtual serial port over the network.

The actual payload of course is application-specific, and how you choose 
to process the data after extracting from the IP packet is completely up 
to you.

There's a couple of open-source projects involving serial over ip.

Other 'turn-key' solutions offer boxes that you connect either end of a 
network connection to transparently transport serial data. They're using 
their own abstraction and it's not visible to the user.

Regards,
Mark

packer44@hotmail.com wrote:
> Hi,
> 
> Could anyone lend some light into which protocol or technique is used
> to actually send I/O from a legacy serial port device onto a TCP/IP
> network?  I see there are many products out there, but none of the
> product sites describe the actual protocol used on the IP network side.
>  An RFC search also came up with nothing, though I could have missed it
> as well...  

Hi,

have a look at RFC 2217 "Telnet Com Port Control Option"
http://www.faqs.org/rfcs/rfc2217.html

Greetings,
Frieder

Thanks Frieder,
   I suspect that it is indeed simply a Telnet connection, but no-where
can I confirm that's how it's done, so I imagine that single character
mode is used, and the recieve end does it's own message framing for the
application on the other end.  I'll have to look at how TCP/IP data
payloads are then directed to COM port based applications.

As far as ...
"  ... Other 'turn-key' solutions offer boxes that you connect either
end of a
network connection to transparently transport serial data. They're
using
their own abstraction and it's not visible to the user. "

   I think I already said that...

Thanks,
-D

packer44@hotmail.com wrote:
> Thanks Frieder,
>    I suspect that it is indeed simply a Telnet connection, but no-where
> can I confirm that's how it's done, so I imagine that single character
> mode is used, and the recieve end does it's own message framing for the
> application on the other end.

Telnet isn't a bad way to think of (and debug) it, but a common method
is really just plain TCP to an arbitrary port (with which a telnet
client is sort of backwards compatible).

If your serial link is fast, you probably don't want to put each
character in it's own packet, instead wait a short amount of time and
then send as many characters as you have collected from the serial
line.  Going the other way, when a packet comes in your push all its
characters out the serial - optionally waiting to acknowledge the
packet until you have done so.

You also need to decide what to do on the serial link if your TCP
packets aren't being acknowledged.  Do you just let incoming serial ->
ethernet characters collect in a buffer?  What do you do when it
overflows?

One commercial vendor uses something in the style of the old modem "AT"
command set to control the ethernet link from the serial side.

Frieder,
   Thanks again.  The reason I mention using singel character mode is
that if the system is to be "blind" (to the serial protocol) through
the TCP transport, then you have to transmit a single character at a
time, since some messages may be a single character, but I suppose a
good bet for better efficiency would be to send what data you have
after something like 2-3 character times elapse since the last recieved
character at the serial end.
   One last thought ... how does one choose an arbitrary TCP or UDP
port?  I'll take a look through the RFC's

Thanks Again,
-D

On 2005-10-26, packer44@hotmail.com <packer44@hotmail.com> wrote:

> Could anyone lend some light into which protocol or technique
> is used to actually send I/O from a legacy serial port device
> onto a TCP/IP network?

It depends on the product.  Some use vendor-specific protocols.
Some use a raw TCP/IP bytestream.  Some use UDP/IP.  Some use
telnet (with or without the serial port status/control
extensions).

-- 
Grant Edwards                   grante             Yow!  Like I always
                                  at               say -- nothing can beat
                               visi.com            the BRATWURST here in
                                                   DUSSELDORF!!

On 2005-10-26, packer44@hotmail.com <packer44@hotmail.com> wrote:

> I suspect that it is indeed simply a Telnet connection,

You'd be wrong in many if not most cases.

I've worked on and with quite a few different serial to
Ethernet products, and they use all sorts of different
protocols.  Some of them don't even run on top of IP.

> but no-where can I confirm that's how it's done,

It is in some products, some of the time.  Search for products
that mention RFC 2217 in their specs.

> so I imagine that single character mode is used, and the
> recieve end does it's own message framing for the application
> on the other end.

You have a good imagination, but I'm not sure what you're
talking about by "receive end" and "message framing"

> I'll have to look at how TCP/IP data payloads are then
> directed to COM port based applications.

In general, the vendor writes a device driver for the OS in
question that presents one or more "COM ports" to the user via
the normal kernel API.  In some OSes there are user-space ways
of pretending to be a tty/serial port, but they don't always do
a very good job of emulating the behavior of a real kernel-space
driver.

The only "standard" that exists is telnet plus the RFC2217
serial port control extensions.  However, a lot of devices
don't use that protocol.  There is at lease one "COM port"
driver for Win32 that implements Telnet+RFC2217, and you can
use that driver with any device that implements Telnet+RFC2217.

-- 
Grant Edwards                   grante             Yow!  Yow! Is my fallout
                                  at               shelter termite proof?
                               visi.com            

On 2005-10-26, packer44@hotmail.com <packer44@hotmail.com> wrote:

> One last thought ... how does one choose an arbitrary TCP or
> UDP port?

Well, if you look up the definition of "arbitrary" that pretty
much explains it.

-- 
Grant Edwards                   grante             Yow!  Did I say I was a
                                  at               sardine? Or a bus???
                               visi.com            

packer44@hotmail.com wrote:
> Frieder,
>    Thanks again.  The reason I mention using singel character mode is
> that if the system is to be "blind" (to the serial protocol) through
> the TCP transport, then you have to transmit a single character at a
> time, since some messages may be a single character, but I suppose a
> good bet for better efficiency would be to send what data you have
> after something like 2-3 character times elapse since the last recieved
> character at the serial end.
>    One last thought ... how does one choose an arbitrary TCP or UDP
> port?  I'll take a look through the RFC's

The Telnet protocol has special interpretations
for the octets in the range of 240 to 255.

If your serial link is not going to transfer
data in the special octet range, a raw TCP
connection is equivalent to Telnet.

There is a common misuse to call a raw
TCP connection Telnet, as the commonly
printable character range can be handled
with a standard Telnet client.

--

The port ranges in use are listed (among
plenty of other numbers) in the RFC 1700.

The ports up to 1023 are reserved for
pre-determined services. In many hosts,
the ports can be handled by a privileged
program only (Unix: root).

For an entirely private use, pick the
port from 49152 - 65535.

-- 

Tauno Voipio
tauno voipio (at) iki fi