摘要

  • RFC 1207 记录了一组 SunOS 3.5 故障问答：两台 Sun 3/60 以 ttya 串口运行 SLIP，ping、rlogin 正常，NFS 挂载却超时。答复把问题指向默认关闭的 UDP 校验和；SLIP 本身没有补上这道校验。
  • 同一节还指出，SCO 为 Xenix 提供的 SLIP 只配合 SCO 串口驱动，带自有驱动的智能多端口板无法直接使用。接通线路和买到更多端口，都不能代替应用与驱动的实际兼容性测试。

连接成功，是最容易误导人的绿灯

一位网络管理员如果只看最初两项测试，完全有理由把线路故障划掉。两台 Sun 3/60 的 ttya 口连着 SLIP，ping 能到，rlogin 能登录。随后 NFS 挂载等不到回应。RFC 1207 把这个令人烦躁的顺序原样留在问答里：网络可达，远程交互可用，文件系统却停在 RPC 超时。

这份文档不是某厂商的产品手册。G. Malkin、A. Marine 和 J. Reynolds 在 1991 年 2 月整理了资深互联网用户经常在邮件列表上提出的问题，希望给刚接入互联网的网络运维人员一套可用的参考，也减少列表里反复出现的同一道题。它的价值正在于那种“不应该这样”的工作现场：一项检查通过，另一项工作仍然失败。

答复给出了具体原因。文档称 SunOS 3.5 关闭 UDP 校验和；在有链路层校验的以太网上，这项设置可以正常工作。换成 SLIP，串口封装自身没有校验和，NFS 依赖的通信便失去那层保障。答复要求为这类 NFS 使用打开 UDP 校验和，并给出用 adb 修改内核变量 udpcksum 的当年命令，同时提醒保存旧内核。

这里的因果链比“串口线太慢”更尖锐。问题不在机器能否找到对方，而在承载不同工作的协议路径有没有检查损坏的数据。ping 的成功只证明它测试过的往返路径；rlogin 的成功也不能替 NFS 的 UDP 交换签字。把“有连接”盖章成“业务正常”，正是这份问答要拆开的偷懒。

另一块串口板，把驱动边界露了出来

RFC 1207 的同一节还有一桩硬件采购会碰到的尴尬。有人问 SCO Xenix 上的 SLIP 能否配合多端口串口板使用。答案说 SCO TCP/IP for Xenix 支持 SLIP，但只适用于 SCO 的串口驱动。智能串口板若带自己的驱动，那个组合便不能工作。需要大量 SLIP 端口的人，答复建议使用多个较简单的串口，或者多端口的“笨”板。

端口数越多，硬件听起来越高级；软件却不认它的驱动。这个例子与 NFS 超时并非同一处故障。前者卡在驱动与 SLIP 实现的接口，后者卡在串口封装和 UDP 校验之间。两者合在一篇资深用户问答中，给出了一幅很不浪漫的早期接入图景：机柜里有线、有板、有操作系统，还得逐层证明它们真能一起完成工作。

文档前面还纠正了一次基础判断：SLIP 为异步串口设计，PPP 则可用于异步或同步线路。把介质类型记反，会在选型的第一步走错。接着，驱动案例告诉人们“支持 SLIP”的产品描述还不够；NFS 案例又告诉人们“SLIP 正在传包”也还不够。不同的成功各有边界，跨过边界就得拿出新证据。

答复给了修法，档案没有替用户跑完

问答提供了历史上的内核修改命令，而且是直接改运行内核变量的那种实用写法。它说明编辑者认为控制点就在本机的 UDP 校验设置，而不在远端 NFS 服务器的名字或一根新电缆。它没有附上修改前后的抓包、服务器日志或成功挂载记录；这些资料才能确认那一组机器最终是否按建议恢复。

RFC 1207 的导言也交代了档案性质。材料来自多个邮件列表，有的答案被压缩；编辑者会补上原问题未收到的答案，未必给这类补答单独标注；额外补充材料则另列标题。来信人姓名被移去。读者得到的是一套经过整理的运维经验，而不是可以重放的事故记录。

故障在纸上仍然足够清楚：串口链路接通了，NFS 却超时。答案把排查从应用表象带到缺失的校验层。1991 年，互联网扩张意味着更多地方会把已有机器接进来；真正的入网考试不只考网络灯亮不亮，还考用户打算在那条线上做什么。

来源