Summary

  • RFC 1207 preserved a SunOS 3.5 support case: two Sun 3/60 computers linked through their ttya serial ports could ping and use rlogin, yet an NFS mount returned server not responding: RPC Timed Out. The answer blamed disabled UDP checksums over SLIP, which added no checksum of its own.
  • The same FAQ warned that SCO’s SLIP for Xenix worked only with SCO serial drivers, not intelligent multi-port boards with their own drivers. In both examples, a working connection was a narrower fact than a working service or a compatible board.

The green light that missed the file share

An operator in RFC 1207 had done the reassuring checks. SLIP ran between the ttya ports of two Sun 3/60 workstations. ping returned; rlogin opened a session. Those results would normally move a network fault down the list of suspects. The NFS mount then returned a different verdict: server not responding: RPC Timed Out.

The question appeared in an FYI aimed at experienced Internet users, compiled by G. Malkin, A. Marine and J. Reynolds in February 1991. Its editors had watched major mailing lists, collected recurrent questions and assembled answers for operations teams, especially those on networks joining the Internet. They wanted useful knowledge to circulate without making every subscriber read the same troubleshooting exchange again. One of their examples showed why that work mattered: “the line is up” was not an answer to a file service that would not mount.

The FAQ’s diagnosis was specific to this configuration. It said SunOS 3.5 turned off the UDP checksum. On Ethernet, link-level checking could make that choice seem harmless in ordinary use. SLIP did not supply a checksum. For NFS over that serial link, the FAQ said to turn the UDP checksum on. It even gave a kernel-patching command and advised keeping the old kernel. The advice reached into an operating-system setting because the missing protection sat below the failing application.

That is a more interesting failure than a dead cable. ping and rlogin could demonstrate reachability and an interactive path while leaving a UDP-dependent file operation exposed to a different integrity condition. The FAQ did not include a packet capture or a report that the patch was applied and fixed the mount. It documented a diagnosis and a proposed change. The distinction matters because the one visible outcome in the source is the timeout, not a successful repair.

A small serial line carried several different bets

Section 8 of the FAQ began by correcting a reversed recollection. One user thought SLIP ran only on synchronous serial lines. The answer said the opposite: SLIP was designed for asynchronous lines; PPP could operate on asynchronous or synchronous links. That exchange put the support cases in their period. Network teams were deciding how to attach hosts by serial circuits and which software could run on the equipment already in a rack.

The SunOS example then separated three kinds of success. The serial ports and SLIP interface carried packets. Some applications could use the path. NFS could not complete its mount in the described setup. A single status light would have flattened those observations into “connected.” The source instead forced the operator to ask which transport a service used and which layer checked the bytes on this particular path.

The FAQ’s other section 8.3 answer added a hardware trap. SCO TCP/IP for Xenix supported SLIP, but its implementation worked only with SCO serial drivers. Intelligent multi-port boards that supplied their own drivers would not work with that SCO SLIP combination. An operator planning many serial lines might buy the more sophisticated board and discover that the driver, rather than the number of physical ports, blocked the project. The answer suggested multiple simpler ports, perhaps a multi-dumb-port board.

These were different defects with the same operational shape. A product name in a compatibility list did not guarantee every board underneath it. A serial connection that answered one kind of probe did not guarantee a network file system above it. The expensive mistake came from moving evidence across a boundary it had not crossed: from driver support to board support, from packet reachability to NFS reliability.

The patch was an instruction, not a completed event

RFC 1207 printed the historical adb command that would change udpcksum in a running SunOS kernel and told readers to save the old kernel. That unusually concrete answer shows where the editors expected the control knob to be. It also shows the burden placed on local operators: a file-share failure could require them to know a kernel variable, the serial-link framing and the integrity behavior of a different LAN medium.

The document was a compiled question-and-answer record, not an incident report. Its introduction says some list answers were shortened, some unanswered questions received editorial answers without a separate label, and extra editorial material appeared under “Additional Information.” Names of correspondents were removed. In the SunOS exchange, a dated packet trace, the checksum setting before and after, and the NFS result after the change are absent. Those records would decide whether the published diagnosis resolved that installation.

What the printed case establishes is already sharp enough. The machines could exchange traffic, and a file mount failed. The proposed fix lay in a checksum the lower serial layer did not provide. The 1991 operator’s job was not to admire the successful ping; it was to find the first layer whose promise the failing workload actually needed.

Source