Summary

  • On 29 October 1969, Charley Kline at UCLA tested remote login to Bill Duvall’s SRI host. The L and O arrived; the SRI host crashed when Kline entered G, according to Kleinrock’s later account.
  • Kleinrock blamed memory overflow in the SRI host, not the UCLA machine, either IMP or the long-haul line. A small software change let the next attempt work. The handwritten UCLA log records the host-to-host success in six words.
  • RFC 1 had already drawn a line between software in the IMP network and software in each host. The login test made that division visible in operation: a network could carry input to another machine, while the remote machine still had to process it.

Analysis

The command was a test with a human witness

The login exchange was designed to behave like a user opening a remote time-sharing session. Kline would type L-O-G; the SRI computer was expected to supply I-N, completing “LOGIN” on the UCLA terminal. The test reduced a large promise—one computer operating through another—to a tiny sequence that both rooms could observe.

Kleinrock remembered Kline in UCLA’s room 3420 and Bill Duvall at SRI. The teams kept a telephone connection open so each side could confirm the letters. The call did not carry the ARPANET data. It let the people at the two ends compare what the machines had done. In the early network, a spoken “got it” sat beside the packet path as a practical receipt.

The arrangement was revealing. A network diagram could show two attached hosts; it could not show whether SRI’s operating system would accept a remote command, allocate the memory it needed, and return a usable response. The login test crossed that gap one letter at a time.

The final letter found the fault

Kline entered L. Duvall confirmed it. O arrived as well. When Kline typed G, the SRI host crashed. Kleinrock’s 2012 oral history attributes the failure to memory overflow in SRI’s host. He specifically ruled out the UCLA host, both Interface Message Processors, and the long-distance line as the cause. The team changed a little software, tried again, and succeeded shortly afterward.

That boundary matters because “the network failed” would assign the repair to the wrong place. The reported failure was at the destination host, where network-delivered input met a program and an operating system. The IMPs had carried the exchange far enough for the remote host to encounter the command. The repair belonged to the SRI software team.

Kleinrock’s diagnosis comes from a 2012 oral-history interview; the public record contains neither an SRI crash dump or code record to trace the memory fault nor a packet trace separating the failed G from the retry, which would attach the 10:30 p.m. log time to a specific attempt.

Six words had to carry the event

The Computer History Museum’s 1960s account identifies handwritten UCLA logs as the evidence for the first UCLA-to-SRI host-to-host connection on 29 October. It says the first login attempt crashed the SRI host and the next worked. The museum links the UCLA IMP log image. The museum’s captioned archive record assigns the event to 10:30 p.m. and identifies the UCLA and SRI endpoints. The page is part of the museum’s November 21 entry; its caption describes the October 29 logbook record.

Kleinrock later called Kline’s entry the only record of the event. The line reads, “Talked to SRI host to host.” It records a completed relation between two hosts. It does not record the failed letter, the memory diagnosis, the repair or the retry. Those details come from the oral history. The six words are evidence of the successful connection; the surrounding chronology comes from a witness and the museum’s account of its logbook.

The short line remains useful precisely because it shows what Kline chose to record, while the oral history supplies the sequence around it.

The common network stopped at the host boundary

On 7 April 1969, Steve Crocker’s RFC 1, “Host Software”, described network software as divided between the IMPs and the respective hosts. It said BBN specified the IMP software and the host groups had to agree on host software. That contemporary document makes the October failure legible without turning it into a morality tale about one machine.

The shared layer could deliver a message to a host address. The endpoint still owned the code that interpreted the command and kept the session alive. The route, the host interface and the login program had different jobs, and each had a different operator. The failure on G surfaced that division in the most economical possible way: two letters worked, the third ended the remote computer’s run.

The arrangement also limited what anyone could declare complete. A packet reaching SRI was a transport result. A usable login required the SRI host to continue running and return the expected characters. Kline and Duvall could observe that result together; the log could preserve a short record of it. No single network-level success counter could substitute for the application’s answer.

A milestone with a repair ticket

Later histories often compress 29 October into the first message or the birth of the Internet. The underlying event is more useful in its precise shape: a remote-login test on an operating network, a host crash at a particular input, a software correction, and a successful retry. The system’s first memorable exchange had an endpoint bug and a human on the other end of a telephone line checking the result.

That story does not need a perfect origin myth. It shows what an early network actually asked of its participants: agree enough on the common interface to exchange data, then make each host capable of doing something with it. A small shared specification left consequential work at the ends. The October test supplied a clear answer about the first attempt: the network path got the G to SRI; the host could not carry the session through it.

Sources