RFC 2217 Serial Control: Baud Rate and Modem Signals Across TCP

A raw TCP tunnel can carry serial bytes without providing any way to change the remote baud rate, observe CTS or control DTR. RFC 2217 adds a serial-control vocabulary through Telnet negotiation. That capability is useful only when the client and access server agree on control framing, supported hardware and the difference between requested and applied settings.

This guide uses RFC 2217, October 1997, an Experimental RFC, together with Telnet RFC 854 and binary-transmission RFC 856. It is an implementation and acceptance guide, not a claim that every “virtual COM” product implements this protocol or that the RFC provides a modern secure transport by itself.

Identify the data plane and the control plane

Write down which application needs remote serial settings, which endpoint owns the physical port, and whether the existing host expects a local serial API, RFC 2217 or a vendor driver. A generic raw-socket client will not automatically understand interspersed Telnet commands. A proprietary virtual COM utility may use a completely different protocol despite presenting the same operating-system interface.

Inventory required controls before choosing compatibility tests: baud rate, data size, parity, stop bits, flow control, break, DTR, RTS and modem inputs. Separate “required,” “optional” and “not physically present.” A two-wire adapter with no modem-control pins cannot provide real CTS observations merely because the network protocol has a field for them.

Negotiate the option before sending controls

RFC 2217, sections 1–2, assigns COM-PORT-OPTION number 44. Its control messages follow Telnet option negotiation and subnegotiation. In the typical role arrangement, the client offers WILL and the access server answers DO for this option. Record negotiation refusal as a capability failure rather than continuing as though configuration commands were accepted.

For arbitrary binary serial data, also establish the needed Telnet binary transmission behavior in both directions under RFC 856. Binary mode and COM-PORT-OPTION solve different problems: one preserves binary data semantics, while the other controls the remote serial port. Successful negotiation of one does not imply the other.

Escape IAC without damaging serial payload

Telnet reserves byte 0xFF as IAC, the command introducer. A literal payload 0xFF is represented by a doubled IAC sequence, including in binary mode. This rule follows RFC 854’s command format and RFC 856. Escaping also matters when 0xFF occurs inside subnegotiation values.

Implement a stateful decoder that distinguishes ordinary data, escaped IAC, option negotiation and subnegotiation. Network reads can stop between either pair of escape bytes or inside a control command. Do not strip every 0xFF, and do not send control sequences to the UART as application data. Test all byte values, especially 0x00, 0x0D, 0x0A and 0xFF, through a safe loopback fixture.

Compare acknowledged settings with requested settings

RFC 2217 encodes a baud-rate request as a four-byte network-order value. For a synthetic request for 9600 bit/s, the value bytes are 00 00 25 80. The client SET-BAUDRATE command is 1 and its server acknowledgement is 101 decimal. Other serial-setting controls have their own command and acknowledgement codes.

The acknowledgement reports the setting in use, which can differ from the requested value, according to section 2. Treat a missing or mismatched acknowledgement as unresolved configuration. Do not begin a timing-sensitive device exchange simply because TCP acknowledged receipt of the control bytes. Configure the required format, verify returned values and keep a record of any unsupported combinations.

Map modem signals to actual hardware capabilities

DTR and RTS are outputs that may be controlled where supported; CTS, DSR, carrier detect and ring indication are observed inputs. Define the source of each reported state and whether it is physical, synthesized or unavailable. Set notification masks deliberately so the application receives the changes it needs without treating silence as an asserted signal.

Changing DTR or RTS can reset or otherwise affect some connected equipment. Test controls only on an approved fixture with known wiring. Do not assume network-driven RTS toggles can satisfy RS-485 direction timing: the access server may need local automatic direction control. An acknowledgement of a requested line setting does not prove the voltage changed at the connector.

Keep flow control, ownership and security explicit

RFC 2217’s network-side suspend/resume commands are distinct from UART hardware flow control and from payload XON/XOFF conventions. Document where buffering and backpressure occur. Define one owner for configuration changes; otherwise two applications can disagree about the serial format while both believe their writes succeeded.

The RFC does not by itself create an encrypted authenticated channel. Protect deployment with an appropriately authenticated access path and restricted reachability, and document where plaintext remains. Section 6 recommends returning the serial port to an administrator-defined or factory configuration after a session ends. Verify actual reset behavior so a later client does not inherit an unexpected control-line state or baud rate.

Accept a complete control-and-data contract

Use a compatible client and isolated serial fixture to check negotiation, binary round trips, every required configuration acknowledgement, notification masks and session-end reset. Split control sequences at each byte boundary in a software test. Include an unsupported baud rate and a refused option, checking that neither produces a false “configured” state.

• Raw serial data and Telnet control never leak into one another.
• Requested and acknowledged serial settings are compared explicitly.
• Modem signals have documented hardware provenance.
• Port ownership and restoration behavior are deterministic.
• Authentication, encryption and exposed management paths are reviewed separately.

The resulting compatibility record establishes which controls and byte semantics work for the selected client, server and firmware. It does not guarantee transparent serial timing, electrical compatibility or safe remote control of arbitrary equipment.