RFC 2217远程串口控制：通过TCP配置波特率与调制解调器信号

普通TCP隧道可以搬运串口字节，却未必能够修改远端波特率、观察CTS或控制DTR。RFC 2217通过Telnet协商加入远程串口控制能力，但只有两端对控制封装、硬件支持及“请求设置”和“实际设置”的区别达成一致，这种能力才真正可用。

本文依据一九九七年十月的实验性RFC 2217，以及Telnet RFC 854和二进制传输RFC 856。内容用于实现与验收，不意味着每个“虚拟串口”产品都支持该协议，也不意味着它单独提供现代安全传输。

明确数据通道与控制通道

先说明哪个应用需要远程配置、哪个端点拥有物理串口，以及现有主机使用本地串口API、RFC 2217还是厂商驱动。普通原始套接字客户端不会自动理解穿插在数据中的Telnet命令。某个虚拟串口工具虽然提供相同系统接口，底层也可能采用完全不同的私有协议。

列出必须支持的波特率、数据位、校验、停止位、流控、BREAK、DTR、RTS和状态输入，并区分必需、可选、物理上不存在。没有调制解调器控制引脚的两线适配器，不会因为协议里有CTS字段就具备真实CTS观察能力。

RFC 2217第1至2节为COM-PORT-OPTION分配编号四十四，控制消息遵循Telnet选项协商及子协商格式。典型角色中，客户端发送WILL，接入服务器以DO接受。若选项被拒绝，应记录能力失败，不能继续假装配置命令已经获准。

传输任意二进制串口数据时，还应按RFC 856建立两个方向需要的二进制传输行为。二进制模式负责数据语义，串口选项负责远端配置，它们是不同能力，一项协商成功不能代表另一项也成功。

Telnet保留0xFF作为命令引导字节IAC。负载中的真实0xFF要表示为连续两个IAC，即使在二进制模式也一样，依据RFC 854命令格式及RFC 856。子协商数值内部出现0xFF时，同样要考虑转义。

解码器应保持状态，区分普通数据、转义IAC、选项协商和子协商。网络读取可能恰好停在两个转义字节之间，或控制消息中间。不能删除所有0xFF，也不能把控制序列送到UART当作业务数据。可在安全环回夹具中测试全部字节值，尤其零、回车、换行和0xFF。

RFC 2217用四字节网络序表示波特率。合成的九千六百比特每秒请求使用数值字节00 00 25 80；客户端SET-BAUDRATE命令编号为一，服务器对应应答编号为十进制一百零一。其他串口参数各有自己的命令和应答编号。

第2节说明，应答返回实际采用的设置，可能不同于请求值。缺少应答或返回不一致时，应把配置保留为未解决状态。TCP确认收到控制字节，并不意味着可以开始依赖新串口格式的设备交换。先配置所需格式、核对返回值，再记录不支持的组合。

DTR、RTS是可能受控的输出；CTS、DSR、载波检测及振铃指示是观察输入。必须说明每个状态来自物理引脚、软件合成还是根本不可用。通知掩码应按需求设置，不能把“没有收到通知”直接解释为某条信号保持有效。

部分设备可能因DTR或RTS变化复位或进入特殊状态，因此只能在已批准、接线含义明确的夹具上测试。网络侧切换RTS也不能自动满足RS-485收发方向时序，接入服务器可能需要本地自动方向控制。收到线状态设置应答，不代表连接器电压已被实际测量。

协议中的网络暂停、恢复命令不同于UART硬件流控，也不同于负载中的软件流控字符约定。应明确各层缓冲及背压位置，并指定配置修改的唯一所有者，否则两个应用可能都认为设置成功，却对当前串口格式持有不同理解。

RFC 2217本身不会建立经过加密和身份验证的通道。部署时应限制可达范围，采用适当的认证访问路径，并标出仍存在明文的位置。第6节建议会话结束后恢复到管理员定义或出厂串口配置；应验证产品实际恢复行为，避免下一客户端继承意外波特率或控制线状态。

用兼容客户端和隔离串口夹具检查选项协商、二进制往返、每项必需配置的应答、通知掩码及会话结束后的恢复。软件测试应在每个字节边界拆开控制序列，还应加入不支持的波特率和拒绝选项，确认它们不会产生虚假的“配置完成”状态。

记录测试端点、固件、客户端版本、协商日志及串口观察方法。软件环回可以发现转义或状态机问题，但不能替代引脚接线验证；同样，串口能回传文本也不足以证明全部二进制字节和控制命令都正确。

最终兼容性记录只说明选定客户端、服务器及固件的哪些控制和字节语义成立，不能保证透明保留串口时序、保证电气兼容，也不能证明远程操控任意设备都安全。