Home/Support/Support Forum/RFC 2217 Compliant?
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

RFC 2217 Compliant?

0 votes
We're using DigiOne SP and DigiConnect devices in a cabled undersea observatory. Our shore based data acquisition system runs Linux and uses RealPort for redirection of the serial ports. For various reasons too complicated to go into here, I'd like to bypass the RealPort drivers and have the acquisition talk directly on a socket to the Digi's. Hence my question --

Are the Digi devices RFC 2217 compliant? If we have software that can speak RFC 2217, can I bypass the RealPort Linux drivers, and talk directly to the "RealPort" TCP port of the DigiOne? Thanks.
asked Aug 15, 2007 in Realport by BobH New to the Community (4 points)

Please log in or register to answer this question.

8 Answers

0 votes
RFC 2217 is enabled for the Digi One SP (at least in the current firmware of 82000774_G, not sure about previous versions of firmware). As far as bypassing the Realport driver, yes, its possible to use the Digi One SP in this manner by setting the profile as "TCP Sockets". The serial port will then be accessible using the IP of the Digi and connecting to TCP port 2001 (ascii) or 2101 (binary), presuming TCP Base Socket 2000 hasn't been changed from default.
answered Aug 15, 2007 by michaelt Veteran of the Digi Community (769 points)
0 votes
I'm not sure I fully understand; I'm still a novice at use the Digi devices.

If the Digi RealPort driver is using RFC 2217 to the "RealPort" port of 771, why can't I leave the configuration as "RealPort", open a socket to port 771, and start talking RFC 2217?

It's not that I mind changing the configuration and talking to port 2001. It's just that I'm trying to understand the difference. Thanks.
answered Aug 15, 2007 by BobH New to the Community (4 points)
0 votes
The Realport driver communication takes place on TCP port 771, and is used to simulate com ports on the server Realport runs on.

RFC2217 is done native mode, i.e. by connecting directly to the TCP socket that represents the serial port. This is why you'll need to connect to the IP address and TCP port 2001 or 2101.
answered Aug 15, 2007 by michaelt Veteran of the Digi Community (769 points)
0 votes
The 771 socket is strictly used for the RealPort protocol.

It sounds like you will want to communicate directly with the (RFC 2217 compliant) serial port TCP sockets.

This type of connection is commonly referred to as "reverse telnet". A good detailed guide on this can be found at:

http://ftp.digi.com/support/techsupport/hardware/portserver/rtelnet.html

This guide also outlines some advanced features that may suit your environment.
answered Aug 15, 2007 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
Ah, so it sounds like the "Realport protocol" is not RFC 2217, but is a proprietary protocol? That was my misunderstanding. So, if I want to talk RFC 2217, I should talk on port 2001, right?

Where does port 2101 fit into this? How does it differ from port 2001? Does 2101 still use RFC 2217?
answered Aug 15, 2007 by BobH New to the Community (4 points)
0 votes
Yes exactly, RealPort is proprietary.

The 2101 socket is primarily used for binary (raw non-ASCII) data. It is still RFC2217 compliant.
answered Aug 16, 2007 by userid0 Veteran of the Digi Community (2,158 points)
0 votes
Thanks.
So 2101 can pass random binary in both directions? I may need this for some serial devices. I assume, then, that if the serial device sends 0xff, the Digi device will escape that by sending 0xff 0xff, right? Any other characters escaped? Is there documentation on this?

I just tried connecting to 2101, and it appears to act differently from 2001 in other ways. It echoes locally, and it doesn't send until it encounters carriage return. Perhaps these are configurable? Again, can you point me to the appropriate documentation? Thanks.
answered Aug 16, 2007 by BobH New to the Community (4 points)
0 votes
Sorry, the "don't send until new line" appears to have been an artifact of telnetting in from a Linux box. When I telnet in from a Windows box, I get it send character at a time, as expected. It still locally echoes, though.
answered Aug 16, 2007 by BobH New to the Community (4 points)
...