Redirect Serial Port Data over Telnet

In principle yes — RFC 2217 is a published standard, so SEC can interoperate with compliant third-party implementations, including hardware console/terminal servers from vendors like Digi, Lantronix and Moxa that expose the Telnet COM-port-control option, and with software endpoints such as a Linux ser2net/pySerial server. That interoperability is one of the reasons to prefer Telnet mode when you're bridging to non-SEC gear.

The honest qualifier: always bench-test the specific pairing before you rely on it. Implementations differ in which optional RFC 2217 commands they support and how strictly they follow the spec, so a given hardware server might handle baud-rate negotiation but not some signal-line command, or vice versa. It usually works — but "it's a standard" is not a substitute for confirming your two particular devices agree in practice.

Answered by Bohdan Miniv · QA Engineering

The flow-control signals are represented: RFC 2217 carries the control-line state (RTS/CTS and the flow-control mode) between the ends, so hardware handshaking is understood by the protocol rather than ignored the way it is in Raw mode. For setup and for devices where flow control is about correct configuration, this works.

The limitation is responsiveness over a network. Hardware flow control exists to throttle a fast sender the instant a receiver's buffer fills — a real-time reaction measured in character times. Across a network link, the CTS change has to travel back over TCP with its latency and buffering, so it may not arrive fast enough to stop an overrun on a high-throughput stream. On a low-latency LAN it's usually fine; over the internet, don't rely on remote hardware flow control to prevent buffer overruns on a fast device. Where possible, let flow control act locally at the physical port and carry only the data over the link.

Answered by Nikolai Svarachevsky · Lead Developer

Because RFC 2217 negotiates and owns the port's parameters for a single session. The whole point of Telnet mode is that one connected client can set the baud rate, flip signal lines and read port state — and there's no coherent way for two clients to each hold that authority over one physical port at the same time. If two clients requested different baud rates, whose wins? The protocol has no answer, so the mode is defined as peer-to-peer.

That's exactly why Raw mode exists for the one-to-many case: Raw carries no port-parameter ownership, just bytes, so it can safely duplicate the stream to many clients. The trade-off is the flip side of the same coin — Raw gives you multiple clients but no remote port control; Telnet gives you full port control but a single peer. Pick the mode that matches whether you need control or fan-out.

Answered by Nikolai Svarachevsky · Lead Developer

Because RFC 2217 is defined as an option on top of Telnet, which runs over TCP — and it depends on exactly the guarantees TCP provides. The port-control commands (set baud, set signal lines) are negotiated in-band and rely on the stream arriving reliably, in order, with the two ends able to acknowledge each other. That's a connection-oriented conversation.

UDP offers none of that: no connection, no ordering, no delivery guarantee, no acknowledgement. A negotiation that assumes reliable ordered delivery simply can't run over a transport that can drop or reorder the very command that sets the baud rate. So the two modes split cleanly by transport: RFC 2217 signaling belongs on TCP, and UDP is for raw one-way data only. If you need signal/parameter control, you're on TCP by necessity.

Answered by Nikolai Svarachevsky · Lead Developer