Understanding RFC2217 (Virtual Com Ports)

Thread Starter


Joined Mar 4, 2014
I don't own this product, but this https://www.eztcp.com/en/download/pds_files/an_telcom_en.pdf is the quality of the gibberish I've seen on RFC 2217.

RFC 2217: https://tools.ietf.org/html/rfc2217

pyserial: https://pythonhosted.org/pyserial/

ser2net: https://manpages.debian.org/testing/ser2net/ser2net.8.en.html

<network port>:<state>:<timeout>:<device>:<options>
CONTROLPORT:<port spec>

these make some sense.

socat(): https://linux.die.net/man/1/socat

It's my understanding that RFC 2217 generally provides out of band signalling for serial ports:
a) e.g. DTR, DSR, RTS, CTS, CD, RI etc.
b) allows reading and writing of the serial port parameters.
c) The serial port is accessed via a TCP port.

The other option is to use something like Real Port or True Port. These solutions put hardware flow control in the OS. With Linux it requires rebuilding the Kernel with that support.

generally, instructions don't even mention the control port.

This, https://www.elmark.com.pl/amfile/file/download/file/133827/product/24215 is just as bad.

I just don't get how control is implemented AND not sure how to take a given RFC 2217 port, e.g. 5500 and turn it into a /dev/tty or /dev pseudoterminal device.

The intent is to communicate to a serial server (possibly Perle, MOXA or Advantek) from a Rasberry PI 4. Either using the LabView community edition with WXG (web) and Linx (extensions) or use Python.

Besides communicating with the two serial devices, I need some I/O from a webpage. Serial port messages to one device will be outgoing only. The other will have both solicited and unsolicited messages.


Joined Feb 24, 2006
Even in the days when a serial port was an actual thing, hardware flow control was optional. Some slow mechanical device required it, but after about 1975 the use of hardware flow control pretty much faded into obscurity.

BTW - IMHO calling an RFC "gibberish" demonstrates a high order of hubris, and diminishes your credibility among your peers. I would refrain from such value judgements going forward considering that those who wrote them were, and stood on, the shoulders of giants. It is precisely the willingness to put their work out there "for comment" that distinguishes them.


Joined Jan 11, 2015
If you don't understand the history of the Internet RFCs then just picking one can be confusing as in many cases they refer to
each other and/or assume you've read prevous RFCs.

RFC2217 (Telnet Com Port Control Option) adds an option to the Telnet protocol so it assumes you already know the
Telnet protocol. See RFC854 and RFC855 for the basics. There are more RFCs for other Telnet options...


Now Telnet is carried by the TCP protocol which runs over the IP protocol. You can probably mostly skip reading the RFCs
for those by a TCP is mostly just a full duplex byte pipe.

Oh, threre's a wikipedia article on Telnet:


Thread Starter


Joined Mar 4, 2014
I did some more research and I did not realize that there is a second channel WITHIN the data stream. It just took a while to find it. It was burried in here: http://www.tcpipguide.com/free/t_TelnetInterruptHandlingUsingOutOfBandSignalingTheT.htm somewhere.

Without that critical piece of information, little made sense.

With that out of the way, it makes a lot of sense.

I can now do:

sudo socat pty,link=/dev/ttyp1,waitslave tcp:

sudo minicom -z -p /dev/ttyp1 (pty must be in certain form, -z=status & doesn't work)

The socat command is executed in one window and minicom in another.

The link wil stay persistant for 100 seconds, the time set in the serial server.

I haven't found where the default lock file is stored.

sudo, I think, can be removed if the port is a member of dialout.

Back in 1975, I graduated high school, but at the same time we had used Bell 103, 300 baud modems and I got to work for the outfit. They used hardware flow control. the terminal were ASR33's, then Decwriters and CRT terminals.

In the lab, I ended up working for, when the IBM PC came out, anything was possible serial port wise. You had DTR/DSR flow control. You had CTS/RTS messed up. You had the wrong gender connectors.

For terminals software flow control was the norm.

I guess what this tells me so far, is if I can write the application using a TCP API, that's the way to go.

I need to talk to a serial server (Perle, Moxa NPort, or an Advantek) from a Rasberry PI 4. Options at this point, look like the Labview Community edition or python. I never did any python programming.

I'm currently playing with an Advantek EKI-1524 and Linux.