摘要

  • RFC 1317 为 RS-232、RS-422、RS-423、V.35 等相似串行物理链路定义管理对象，并把端口参数、异步/同步错误计数和输入/输出控制信号分开记录。
  • 它明确说明：自动速率识别开启时，网管系统可能暂时看到与先前设定不同的速率、校验方式和字符大小。
  • 因而，设定值与观测值不一致，只能先证明一个端口层差异；它不能单独证明发生过管理写入、某位操作者作出决定、会话已建立、数据已送达或应用取得结果。

屏幕没有自相矛盾

配置常被想象成命令，遥测则像命令的回声。写入一个值，随后应读回同一个值；两者若不同，就去找修改者。这套直觉在许多静态系统里很方便，但 RFC 1317 处理的是会根据输入信号自行适配的物理端口。

该 RFC 的对象并不只覆盖狭义 RS-232。它也包括 RS-422、RS-423、V.35，以及使用相似控制信号的异步或同步串行链路。它把这层 MIB 放在物理层：上面可以是 Character MIB，也可以是 PPP MIB。物理端口向上层提供服务，却不因此拥有上层语义。

所以，一个端口读数可以准确描述连接器一侧的事实，同时对用户、远端设备身份、字符会话、PPP 协商和应用结果保持沉默。依赖关系不是同一性。端口状态不是会话状态，会话状态也不是消息送达或业务成功的凭证。

最值得保留的边界藏在 rs232AsyncPortAutobaud 的说明里。自动速率识别开启后，端口可以识别输入速率，并暂时采用不同于设定值的速率、校验和字符大小。网管系统因而可能看到与先前设定不同的值。这里没有矛盾：一个记录表达先前设定，另一个记录表达当前观测。

同一端口并不是同一类事实

RFC 1317 先记录端口总数，再建立通用端口表。每个端口有本地索引、硬件类型、可检测输入信号数量、可断言输出信号数量，以及输入和输出速率。索引应至少在网管代理相邻两次重新初始化之间保持稳定，并尽可能对应外部连接器。它是表中的坐标，不是远端用户、拨号者、终端或机构的身份。

异步端口另有一张表，保存字符位数、停止位、校验方式、自动速率识别控制，以及校验、成帧和溢出错误计数。同步端口表则保存时钟来源和若干帧级错误计数。输入信号与输出信号也各自成表，分别记录物理控制线的名称、当前状态和变化次数。

这些分表并非繁琐。硬件类型回答“这是什么端口”；设定参数表达管理意图；自动速率识别表达允许的适配机制；暂时观测值表达此刻端口呈现的结果；错误计数表达特定时间边界内被分类的现象；控制信号表达某条线在某个方向上的状态。

若把它们全压缩成“串口状态”，界面会更简洁，证据却会变得含糊。读者再也分不清某个值是被写入、被感知、被累计，还是由本端断言。RFC 1317 的价值恰在于它把这些动词分开。

自动识别打破了镜像假设

自动速率识别并不只是“机器会猜波特率”这么简单。它让设定与观测之间出现一个有明文依据的中间机制。至少需要保存四项事实：先前设定、自动识别是否启用、暂时观测值、以及之后是否需要干预的判断。

假设网管系统显示的字符位数不同于配置记录。该读数先证明采样时刻 MIB 暴露了这个值，并受具体实现和采集路径限制。若自动识别已开启，RFC 已给出一种允许差异存在的机制。它没有告诉我们是哪段输入导致了适配、差异持续多久、是否发生过经过认证的管理写入，也没有证明端口随后是否恢复原设定。

差异更不能识别对端。物理时序可以帮助关联一次连接，却不是身份证明。它不能说明电缆另一端是哪台设备、由谁控制、是否建立 Character 层会话、PPP 是否协商成功。物理层适配只在自己的界面上成立。

因此，看到差异时直接写“配置漂移”仍然过早。“漂移”通常包含持续性、非预期和变更方向等判断。更精确的原始记录应是：先前设定为何值、自动识别已启用、某时刻观测到另一值。要升级成漂移事件，还要补上持续时间、期望状态和变更授权证据。

计数器没有替我们选择原因

异步端口的校验错误、成帧错误和溢出错误看起来更像结论，因为它们有清晰名称。但 RFC 同样限定了统计窗口：自系统重新初始化以来、且端口处于 up 或 test 状态时输入的字符。

计数增加可以证明代理在该窗口内把更多输入字符归入某类错误。它适合触发对参数不匹配、时序、电缆、设备或负载的进一步检查，却不能自行选定原因。校验错误不等于校验配置一定错误；成帧错误不识别发送设备；溢出计数也不能说明哪个应用来不及消费数据，更不能证明业务层必然丢失了什么。

累计值还会丢掉顺序。它不保存每次错误何时发生、当时哪组观测参数生效、哪条信号先变化，也不保存状态持续时间。比较两个采样可以得到区间增量，却仍然不能凭空得到远端身份或因果链。

同步端口的帧校验、发送欠载、接收溢出、中断帧和中止帧也一样。它们是有边界的低层记录，不会自动升级成故障单、客户交易失败或责任结论。计数到原因需要关联，原因到结果还需要另一组证据。

信号名不是行为主体

RFC 1317 还分开定义输入和输出信号表，其中可见 Request to Send、Clear to Send、Data Set Ready、Data Terminal Ready、Ring Indicator、Received Line Signal Detector 等传统名称。每个表项记录信号名、none/on/off 状态和开关变化次数。

这些名称很容易诱发叙事扩张。“Ring”像是有人来电，“Ready”像是某个终端已准备好，“Clear to Send”又像获得了许可。但它们首先是特定物理接口、特定方向上的硬件约定。输入信号是软件可以检测的线，输出信号是软件可以断言的线。检测到一条线不等于认证了远端，断言一条线也不证明对端按预期响应。

变化计数同样只数物理线的翻转，不数呼叫、用户、会话或消息。要把它同上层记录对齐，至少要保留端口索引、方向、信号名、采样状态、计数值、采集时间和代理身份。

1994 年的修订保留了这条边界

RFC 1659 于 1994 年 7 月取代 RFC 1317，并用 SMIv2 重述 RS-232-like MIB。它保留了物理层定位，也保留了自动速率识别的实质说明：端口可能采用不同于设定的速率、校验和字符大小，网管系统可暂时观测到不同值。

这项延续说明，设定与观测的区分不是旧文本里偶然留下的一句话。MIB 修订后，物理机制仍然会破坏“配置必然等于读数”的简单假设。继任 RFC 并不能证明两份规范被广泛部署；它只证明模型作者在修订时继续保留这条边界。

差异需要一组记录，而不是一句判词

严谨的事件记录应当形成一个元组：端口索引与硬件类型、设定的输入/输出速率、校验和字符大小、自动识别状态、带时间戳的观测值、代理重新初始化边界、相关错误计数样本、输入/输出信号状态，以及从其他系统取得的上层接口或会话标识。

把这些记录对齐之后，才有资格追问是否发生了经过认证的管理写入、未授权变更、特定对端触发的适配、持续不兼容或应用影响。变更日志证明谁写了配置；会话日志证明上层是否建立；流量和应用记录证明传输了什么以及产生何种结果。RFC 1317 的一个不同读数，不能替代它们。

这就是一份老式串口 MIB 留下的现代教训：遥测不是操作者的供词。设定值也不是物理机制唯一可以如实呈现的值。屏幕与配置不一致时，第一步应保存两者，并找出中间机制，而不是先发明一个 RFC 从未观察到的改动者、会话或结果。

来源与证据边界

本文依据 RFC 1317（1992 年 4 月）及其 SMIv2 继任者 RFC 1659（1994 年 7 月）。它们支持物理层范围、各表分工、自动速率识别的暂时观测说明、有界错误计数、控制信号状态和取代关系；不证明一台真实设备、一组真实设定、管理写入、操作者、对端、会话、载荷、部署、送达或应用结果。