Sercd is an RFC 2217-compliant serial port redirector. It lets you share a serial port through a network. It is based on sredird. The RFC2217 protocol is an extension to telnet and allows changing communication port parameters. SerLooK is a KDE application for inspecting data going over serial lines. It can work as a binary terminal that sends. It allows you to run the server and the client on linux or windows machines (and. It will redirect virtual serial port COM5 on the second computer to the physical.
A COM port redirector (tty port redirector under Unix/Linux) is specialized software (often including device driver and user application) that includes the underlying network software necessary to access networked device servers that provide remote serial devices or modems.
- 2Variants
- 2.1Virtual serial port
Overview[edit]
The purpose of the redirector is to make the virtual COM port exhibit behavior that closely resembles that of a 'real' COM port, i.e., a COM port driver for local serial port hardware. A virtual COM port itself is a relatively simple software mechanism that can be implemented by driver software similar to that of a conventional COM port driver. The main challenges arise in two other areas: the network connection to the device server and the behavior of the device server. These issues are described in the Technology section below.
Applications use a COM port redirector through one or more virtual COM ports that the redirector creates, as configured by the user. When the application opens the virtual COM port, the redirector makes an IP network connection to the device server at the specified IP address and TCP/UDP port number that corresponds to the remote device on the server. The COM port redirector then begins relaying the application data stream between the virtual COM port and the device server.
A redirector will typically permit creation of many (at least 256) virtual COM ports, but simultaneous use of hundreds of ports is often practically limited by a number of factors, including the memory and processor requirements of the redirector, limits on operating system resources, and the performance of the network stack.
A redirector for the Windows operating system is typically configured using a control-panel style graphical user interface for creating virtual COM ports, configuring settings for individual COM ports, and configuring global settings affecting all COM ports. The redirector GUI typically also includes displays of virtual COM port activity and various diagnostic aids.
The performance of a COM port redirector is determined by both its implementation and the network it uses to reach device servers. The performance drawbacks of simple redirector implementations can be largely addressed by kernel-level drivers that avoid context switches. Network packet loss or excessive packet times have dramatic effects on redirector operation and must be avoided.
COM port redirector software products have been offered by at least 30 vendors dating back to the early 1990s. Compatible networked device servers are currently available from a large number of manufacturers, with a heavy concentration of revenue in the top players, who are based in the North America and Asia/Pacific regions.
The equivalent software for a Unix/Linux operating system is commonly called a tty port redirector and most of the information on this page also applies to it.
Redirectors address a number of issues related to the network connection, including:
- Network protocol support that is compatible with the device server.
- Most device servers are accessed with TCP connections (raw or using the Telnet protocol) to gain reliable delivery of the application's data stream in order of transmission. The majority of server manufacturers use public TCP protocols (raw, Telnet, or Telnet with RFC 2217 extensions). Several of the larger server manufacturers use proprietary protocols in addition to, or instead of, public protocols. Device servers for certain applications, such as those that use wireless networks, use UDP instead of TCP to gain performance at the risk of network reliability.
- Initiating the network connection to a device server and determining that server is ready to relay application data.
- Accepting inbound connections initiated by device servers running in client mode and routing the data stream to a waiting application.
- Flow control of the network data stream to prevent overrun of the server. (This is not the same as hardware/software flow control of the serial device itself.)
- Data rate limiting of the application data stream to provide the performance expected for the baud rate currently in effect on the virtual COM port, which is slower than the maximum speed of the network connection to the server.
- The timing effects of the TCP protocol stack, e.g. network packetization and Nagle's algorithm.
- Network connections through proxy servers.
- Management of the IP routing table to avoid loss of an IP route to the device server.
- Detection and handling of network interruptions, possibly with an automatic attempt to reconnect to the device server to resume application data flow.
Redirectors must also deal with the feature differences of networked device servers related to:
- Visibility and control of serial line signals such as DSR, DCD, CTS, DTR. The redirector may be able to sufficiently emulate these signals.
- Relay of BREAK signals.
- Settings for hardware or software flow control.
- Handling of the network connection when serial devices or modems disconnect.
Because COM port redirectors emulate COM ports on the operating system abstraction level, rather than hardware serial ports, old software which is not written to utilize the operating system, but instead interface directly with a serial microcontroller (hardware ports 0x3F8 to 0x3FF for COM1, for example) will not function with COM port redirectors.
Variants[edit]
Specialized types of redirectors have been offered to meet the needs of certain applications.
A redirector may support back-to-back operation, in which two computers run copies of the redirector and an outbound connection from one results in an inbound connection to the other. In effect, this technique creates a serial communications tunnel through a network connection. In practice, this configuration works only for certain applications but offers potentially lower costs and higher performance using the Internet to carry serial communications instead of modems between two computers.[citation needed]
A redirector may include a modem emulator that allows the application to use 'AT' modem commands even though no physical modem is present. The 'number' dialed is an IP address, and the connection is a TCP network connection instead of a modem telephone call. This type of redirector is generally used by applications in originating client software needs to use a modem but the destination for the connection is a network endpoint. Back-to-back operation of this type of redirector can, in some cases, function as a replacement for modems on two computers for some applications. Network effects on timing of the data stream generally preclude the use of this method for transmitting faxes. Additionally, this method is also not reliable if used for PPP connections (such as dial-up networking) due to architectural limitations of TCP, a topic discussed in technical literature related to TCP-over-TCP.
Virtual serial port[edit]
One variant of a COM port redirector is a virtual serial port. A virtual serial port is a redirector without network software support which is usually used to create a pair of back-to-back virtual COM ports on the same computer. Two legacy applications can then communicate using virtual serial ports instead of conventional inter-process communication mechanisms such as named pipes.
This type of software is capable of emulating all serial port functionality, including Baud rate, data bits, parity bits, stop bits, etc. Additionally, it allows the data flow to be controlled, emulating all signal lines (DTR / DSR / CTS / RTS / DCD / RI) and customizing pinout.
Serial port emulation[edit]
- Serial port emulation is useful especially when there is a lack of available physical serial ports. Communication between software and/or devices which would otherwise require extra physical connections, can be benefited by using a virtual COM Port emulator.
- Virtual serial ports let you send or receive data over a TCP/IP port using any serial communication program. This facility allows creating a full-fledged client-server architecture which provides multiple connections and data sharing possibilities between different applications. Such a connection is the best way to allow use of rare and expensive serial devices by different users simultaneously.
- Using serial port emulation one can split a real COM port between a number of virtual serial ports. This makes it possible to supply data from a single serial device to a number of different applications. Such necessity arises when several applications compete for a single GPS connection and the user must close one program to allow another to access a single GPS device.
- A virtual serial port may have the same name as physical one. This facility allows real serial port overlapping (mapping) and receiving data from a physical port through virtual port. In other words, you can map any serial port or virtual port to any other existing port in your system. In this case applications will work with virtual ports, but, in fact, they will receive data from overlapped real ports.
Specification[edit]
- RFC 854 - Telnet protocol specification
- RFC 2217 - Telnet Com Port Control Option
See also[edit]
References[edit]
SerialToIP - open source Terminal Server software
Further reading[edit]
- Serial Port Complete: COM Ports, USB Virtual COM Ports, and Ports for Embedded Systems; 2nd Edition; Jan Axelson; Lakeview Research; 380 pages; 2007; ISBN978-1-931-44806-2.
Retrieved from 'https://en.wikipedia.org/w/index.php?title=COM_port_redirector&oldid=859694748'
(Serial port or com port? - Serial ports are often refered as COM ports. It is the same to be short. You can read abut it in the Wiki article )
The problem
Suppose we have an application that works with some device using serial port (com port). It could be GPS reader, IRDA, whatever. So it looks like this:
Now what we want, is to have the device connected to one machine (server), and run the application on the remote machine (client) over the network. Real life example: a device is connected to raspberry pi (very small single-board machine) that is connected to a local network, and read the data on a desktop.
Since the application (APP on diagrams) knows only how to communicate with the device by serial port (we suppose), the client machine has to have some virtual serial port that is used by the application:
So now the application just works with serial port on the client machine, and doesn't even know that data is actually transmitted over the network.
The solution in theory
One of the solutions is using telnet with RFC2217 - Telnet Com Port Control Option. Is solves exactly the problem above. There are a lot of software that supports telnet+RFC2217 serial port forwarding. It allows you to run the server and the client on linux or windows machines (and MACs I suppose, but haven't tested it). Thus can, as example, run linux server and windows client, both using completely different packages, but because of RFC2217 they 'know' how to communicate.
More over you can multiplex the com ports and encrypt the data. Whatever you want.
The solution in practice
WINDOWS
There is an absolutely brilliant free opensoure solution that can be used for comport forwarding, client and server for windows. It is called com0com.
Server
For the server you need only hub4com part of it.
Configuration (I just cite the documentation):
You have a server computer with phisical COM1 port and you'd like to share itthrough the network by the RFC 2217 'Telnet Com Port Control Option' protocol:
Start the com2tcp-rfc2217.bat on COM1 port. For example:
It will listen TCP/IP port 7000 for incaming connections and redirect them to COM1 port.
Client
To be a windows client you have to install com0com virtual comport driver.
Create a PAIR of virtual comports where one is used for RFC2217 and the other is the port for your application will use.
(documentation citation) for RFC 2217 client :
You have a server computer your.comport.server with physical serial portshared through the network by the RFC 2217 protocol (see above example) andyou'd like to use it on the client computer like a virtual serial port.
With the com0com's Setup Command Prompt create COM5<->CNCB0 virtualCOM port pair (see com0com's ReadMe.txt for more info). For example:
Start the com2tcp-rfc2217.bat on CNCB0 port. For example:
It will redirect virtual serial port COM5 on the second computer to the physical serial port on the first computer.
Driver Signature
Deprecated part - com0com 3.0.0 comes with driver signarure. But if driver signature bugs you...
According to this bug report and my own experience, on Windows 8x64 you probably will get problem with driver installation if you don't have the driver signature verification turned off.
To enable driver test mode and sign a driver for windows, one may download
DSEO
DSEO
Then run it
Enable Test Mode (if you hasn't done it before)Sign a system file
d:ToolsComOverNetworkcom0com
- is where I installed com0comRestart the system
LINUX:
Server
The linux app I've got working pretty easy is ser2net
It has configuration file located at /etc/ser2net.conf.The configuration line (for /etc/ser2net.conf) that corresponds to windows setup above
Here:
- 7000 - port
- /dev/ttyUSB0 - name of serial port
- 1000000 ... - baud rate etc (actually you can skip it because of remctl)
- remctl - means using remote port configuration as of RFC2217
That is it. Read ser2net docs for more
Ubuntu installation
Client
Mmmm... Can you write it here, please?