25 Feb 1997 Phil Karn, [email protected]
Also see my new Road Runner Braindamage List.
Revised 27 Feb 1997 with notes on the RR firewall blocking outbound packets with non-RR source addresses, and the apparent assignment of different DNS IP addresses depending on physical location
Revised 10 March 1997 with new parameters to the rrlogin program, and to reflect that the IP address of the DNS/authentication server appears to depend on where you are in San Diego.
Revised 14 March 1997 with minor editorial changes and corrections.
Revised 18 March 1997 to note much improved performance on the CERFnet/MCInet path.
On February 20 I had Southwestern Cable install Road Runner cable modem service in my University City house. Southwestern Cable is owned by Times-Warner Cable and provides service in San Diego north of Mission Valley. Road Runner is also currently available in Akron, Ohio; Elmira-Corning, New York; and Portland, Maine.
Road Runner is similar to, but distinct from, the @Home cable modem service that has gotten somewhat more publicity. In San Diego, Cox Cable will be offering @Home in its service area (south of Mission Valley).
The bottom line so far: don't cancel your ISDN service just yet. Naming this service after the Looney Tunes Road Runner character was perhaps even more appropriate than Times-Warner intended. Just like the cartoon character, it can (under the right circumstances) be tantalizingly fast. But its quirks and misfeatures (some of which amount to utter brain damage) also make it intensely frustrating. Like Wile E. Coyote, I've been forced to resort to some rather desperate tricks to get it to work properly in my configuration. While I've been somewhat more successful than Wile E., significant problems remain.
So while Road Runner is extremely promising, I cannot recommend it yet for San Diego telecommuters. The cable modems themselves seem to work reasonably well. But the performance of the existing Internet path between Southwestern Cable and CERFnet is completely unacceptable. CERFnet is the San Diego-based ISP to which many important local Internet sites are connected, including Qualcomm, UCSD and SDSC. If you plan to use the service heavily for telecommuting, you might want to wait until this problem is fixed before placing your order.
Road Runner uses Motorola CyberSURFR cable modems. Physically, the modem closely resembles the old Motorola/Codex 3600-series modems, with a hokey plastic front panel escutcheon molded in the shape of a breaking wave. (Wave -- CyberSURFR. Ugh. Marketing runs amok.) The rear panel has a reset button, a power connector (with an external "brick" supply), a coaxial F-connector for the cable connection, an unused DB-25 marked "ASYNC" and a female RJ-45 10Base-T connector for the local Ethernet connection.
The CyberSURFR Ethernet connector is wired as a hub port (DCE), so it can connect directly to a host computer's Ethernet adapter with a "straight through" RJ-45 patch cable. This is the usual configuration, as the service is primarily intended for standalone PCs without local area networks. If you connect the cable modem to an Ethernet hub, you must use either a "crossover" cable with a regular host hub port or make use of the "upstream" port found on some hubs. (My Allied Telesyn hub has one port with a switch that selects "host" or "hub" mode.)
The front panel has four LEDs labeled Power, Cable, PC and Test. The Power LED has the obvious meaning. The Cable LED lights when the modem has acquired the forward (downstream) signal from the cable system.
The PC LED is the 10Base-T "link" light; it comes on when the Ethernet port is properly connected to a hub or host and the latter is powered on and running.
The Test LED is off in normal operation.
There are no external "packet" LEDs, but there appear to be two LEDs inside the box (partly visible through the ventilation holes) that flash with received and transmitted packets.
Hardware installation was simple and straightforward. Southwestern Cable sent three installers in two separate trucks, which was ridiculous overkill. I had them install the modem next to my Ethernet hub and Ascend ISDN router on a closet shelf I use for networking equipment. When I rewired my house two years ago I installed a foot-long section of 2" PVC pipe through the ceiling above the shelf and into the attic for the Category 5 wiring. The cable installers used this same pipe to run the required coax line from the modem up to a 2-port splitter in the attic. The installers added a high pass filter (apparent cutoff of 50 MHz) to the splitter port that feeds my TVs to help keep the strong low-frequency upstream signal from my cable modem out of my TV sets.
Two of the installers were regular cable TV technicians who installed the cable modem box and hooked it into my cable system. The third was a computer technician who brought an Ethernet adaptor and two setup diskettes.
The Ethernet adaptor that comes with installation is the 3Com 3C508 [sic], a tiny 16-bit ISA-bus card with only a 10Base-T connector. I had never heard of this model before, and it is apparently not software compatible with any other 3Com card, such as the popular 3C509. Windows 95 does not provide a driver for the 3C508, but the installer brought a driver disk that worked fine. But so far I've found no way to make this card work with Linux or BSDI.
There is nothing special about this card. If you already have an Ethernet card in your system, you can use it with Road Runner as long as you can connect to the Road Runner modem's 10Base-T jack.
Here we encounter the strangest, single most brain damaged part of the Road Runner service: the login program. Although cable modem services are supposed to provide continuous LAN-like connectivity to the Internet, the Road Runner service requires that each computer "log in" to the network before it can send any packets.
The login program is provided for Windows 95 and for the Macintosh. The computer technician on the installer team installs it for you and leaves you the disk in case you have to install it again.
The login program presents a dialog box with fields for a user name and password that are provided on your service order form. When you log in successfully, the program plays a sound file of the Looney Tunes Road Runner saying "meep! meep!" and automatically launches a web browser. The default browser is Microsoft Internet Explorer. At setup time, the technician downloads this over the cable modem and installs it on your computer.
The sound file is cute the first few times, but it gets old quickly. There's no direct way to disable it, but you can overwrite or delete the .WAV file.
You can have the login program launch a different web browser, such as Netscape. But there doesn't seem to be an option to not launch anything at all, except by configuring the login program to launch a no-op program.
You can not close the login program after you've logged in, but you can minimize the window. The login program continues to send "keepalive" packets to the system, without which you are eventually logged off. More about this in the next section.
A colleague and I spent some time analyzing the login procedure. The Road Runner login program is available only for Windows 95 and the Mac. So Linux, BSD and other UNIX variants are unable to use the Road Runner service as supplied. This supplied considerable motivation.
The Road Runner service assigns dynamic IP addresses via the DHCP (Dynamic Host Configuration Protocol) as specified in RFC-1541 and RFC-1533. DHCP is standard with Windows 95, Mac-OS, Linux and the various flavors of BSD. DHCP service is available on many corporate networks; both servers and clients are widely available.
The DHCP client is typically started by the computer at boot time. Assuming the cable modem is connected and operating properly, the DHCP server in the cable system (in my case, IP address 204.210.7.25) will assign a dynamic IP address. These addresses are "leased" for a limited time (typically one hour) and are renewed periodically by the DHCP client daemon.
In the University City/Clairemont area, the IP addresses appear to be assigned in the range 204.210.[35-38].*. Several other pieces of information are also returned to the client in the DHCP response, including the (incorrect) netmask (255.255.255.0), default router (204.210.n.1, where n is the same as the third digit of the assigned IP address), and the IP address of a local domain name server (204.210.7.25). (Note: the assigned domain server depends on where you are in San Diego -- there appear to be twelve different regions.)
There seems to be no problem obtaining addresses for several computers connected to a single Road Runner modem through a hub. The installer mentioned a limit of 8 simultaneous client computers on a single cable modem, but I have not verified this. I do know it works for at least three.
On most networks, a DHCP client is the most you need to get going (unless you already have a static address, in which case you don't need DHCP). But with Road Runner, you still can't reach the outside Internet. A packet filter blocks all upstream packets from your computer except packets to UDP port 53 (DNS) and TCP packets to port 7283 on the IP address given by DHCP as the DNS server. This same host also functions as the Road Runner authentication server. ICMP packets (e.g., ping) to the outside Internet are also unblocked before login. The firewall only seems to block reverse link packets; forward link packets to your system appear to be unblocked.
The login program prompts the user for his login name and password. Then it does a DNS lookup for the Road Runner authentication server "tas.san.rr.com", which is why the firewall allows DNS requests in the logged-out state. The IP address returned for tas.san.rr.com apparently always matches the DNS server given by the DHCP server. Again, the specific address depends on where you are in San Diego.
The login program then opens a TCP connection to port 7283 on the authentication server. The following exchange ensues over the TCP connection, assuming the Road Runner user name is "username", the user's password is "PASSWORD", the DHCP-assigned IP address is 204.210.32.20, and the client is running Windows 95. "C:" indicates messages sent by the client and "S:" indicates messages back from the server.
C: 01,01,0000,00000065,username,PASSWORD,204.210.32.20 ,WIN-95 ,'\0' S: 01,02,0000,00000042,02,01,00,00,username,'\0' C: 02,03,0000,00000075,WIN-95 ,1 ,rrie95.exe ,1.0.0.1 ,'\0' S: 03,01,0000,00000021,'\0' C: 03,02,0000,00000021,'\0' S: 90,03,0000,00000021,'\0'
The TCP connection then closes.
Each message is an ASCII string terminated with a null byte. Each field is of fixed length and is padded on the right with blanks if necessary. The meaning of some of the fields is unknown but many others are fairly obvious: the user name, password, IP address, OS name, Road Runner software file name and version, etc, are all in the clear. The 4th field containing 8 digits appears to be the length of the message in bytes, including the null terminating byte.
The OS, executable file and version number fields are for an automatic software update mechanism. When the program is first installed it automatically downloads a fair bit of software from the Road Runner server, including Microsoft Internet Explorer. On subsequent logins the program will check to see if a newer software version exists. If so, it will (optionally) download it.
After the TCP connection closes, the login program continues to send UDP "keepalive" packets to the authentication server once per minute. The source port is 6285 and the destination port is 6284. The packet contains the following null-terminated ASCII string:
99,03,0000,00000038,204.210.36.20 ,'\0'
If the login succeeds, the standard login program plays an audio file of the Looney Tunes Road Runner saying "meep! meep!" and taking off down the road. It then launches a web browser. There doesn't seem to be any direct way to disable either of these misfeatures, though you can configure the login program to launch a "no-op" program as your web browser, and you can overwrite the .WAV file of the Road Runner sound effect (or you can turn down the volume on your soundcard). You can still launch your web browser manually.
The only explanation for all this "login" braindamage (given that there are far less annoying ways to learn of web browser version updates) is to implement a parental control mechanism. The user manual talks about creating subaccounts with "basic" (restricted) access to the net. Although I have not confirmed this yet by experiment, it seems reasonable that clients signing in with a restricted account would be firewalled to a proxy web server with "sanitized" content for kids.
I have written a C program to emulate the login protocol.
It pretends to be a Windows 95 system. If the Road Runner WIN-95 software revision has incremented, the client declines to download it. It also does not automatically launch a web browser, and it does not play the "meep! meep!" sound effect file. It does, however, compile and run successfully under Linux and BSDI. The program usage is as follows:
rrlogin [-l] [-v] [-t timeout] [-h authhost] [-p proxyaddr] [logname [password]]
The -l flag specifies that the Road Runner "logout" message should be sent before the login protocol is executed. (If the user is already logged in, the login procedure will fail.) This doesn't seem to work; also, if you're already logged in, the login program will just start sending keepalives -- which should keep you logged in. The poor design of the Road Runner login protocol makes it difficult to be sure of having covered all the bases, but it seems to work pretty well.
The -v flag enables tracing of the login protocol messages.
The -t option specifies the interval in seconds between keepalive messages. The default is 60 seconds, the same as the standard login program.
The -h option allows you to override the name of the authentication host. It can be specified as either a domain name or an IP address. The default is "204.210.7.25", corresponding to tas6.san.rr.com. If you are not in University City or Clairemont, you will have to specify the IP address of the correct authentication server. You can obtain this address by running WINIPCFG.EXE under Windows 95 and looking for the IP address of the DNS server returned by DHCP when you booted your system.
Note that before login the Road Runner firewall lets you send DNS requests only to the Road Runner-provided DNS server. A system that runs its own name daemon that talks to the "real" DNS root servers (e.g., named) will cause the login program to deadlock if it references the authentication server by domain name rather than IP address.
The -p option specifies the HTTP proxy system. The login program will open a TCP connection to port 8080 on this host once per minute to verify that it is still logged in. If the connection succeeds, it is immediately closed; if it times out, the login process is automatically repeated.
The Road Runner login name and password can be specified on the command line. If the password (or the password and the user name) are not given, the program will prompt for them.
The login program does not exit, as it must keep sending keepalive packets and testing connectivity to the proxy host. It is therefore a good idea to start it as a background daemon, with the login name and password as command line arguments.
Like most regular Internet Service Providers (ISPs), Road Runner provides more than raw IP connectivity to the Internet (though the potential speed of this connectivity is the only feature of any real interest.) The San Diego Road Runner service provides:
These names were "hardwired" into the customized version of Internet Explorer that is downloaded at installation time. If you want to use Netscape Navigator, you have to configure it manually.
No UNIX shell services are advertised.
Some web content is available only to Road Runner users. Most of this appears to be hosted off the Time Pathfinder site, pathfinder.com. At present there doesn't seem to be anything of value there, which is interesting considering all the hype that Time-Warner has made about Road Runner providing more than just a pipe to the Internet.
Now we get to the really interesting stuff. Road Runner is supposed to be fast. The Motorola cable modems are rated at 27 megabits/sec downstream and 768 kilobits/sec upstream. Do they deliver? How reliable are they?
After some initial hiccups, the cable modem link seems to work pretty well. Here are the summaries of some ping tests conducted during the first few days after installation:
ping 204.210.7.25 (DNS and login server): 4.343/50.02/2022.89ms (min/avg/max round trip time); 38706 pings sent, 38326 received (<1% loss).
ping 204.210.0.22 (web proxy): 4.956/59.42/2019.67ms; 38589 pings sent, 38222 received (<1% loss).
ping 204.210.36.1 (default router given by DHCP): 6.177/172.345/1170.87ms; 435 pings sent, 435 received (0% loss).
Although the packet loss rates were reasonably low, the variance of the round trip time was troubling. But when I repeated the tests on Monday Feb 25, the average delay had decreased noticeably, and the packet loss rate had gone to zero:
ping 204.210.0.21 (web proxy): 5.048/20.727/1111.37ms; 2856 pings sent, 2856 received (0% loss).
I attribute the long-delayed packets as either indicative of congestion on the reverse link, or perhaps the retransmission delays of an ARQ protocol affected by noise or interference. It will be interesting to test the reverse and forward links separately.
I have not yet tried to speed-test the forward link.
Southwestern Cable's sole connection to the external internet is through MCInet, while many important San Diego internet sites are on CERFnet, physically located at the San Diego Supercomputer Center. The only apparent connection between these two networks is at MAE-West up in San Jose. This is a major West Coast Internet tie point that is notoriously overloaded. Packet losses between CERFnet and MCI consistently run 15-30%, which is unacceptable. (TCP was designed to run well with packet loss rates of 1% or below). As an example of how bad it can get, on Monday I FTPed a 15 megabyte file from home to SDSC, which is also on CERFnet. Average throughput was about 3500 bytes/sec, which is about what you can get with a 28.8 kb/s modem. Packet tracing revealed long pauses due to dropped packets causing TCP to back off on its retransmissions. Although I have not yet tried a large forward link transfer, I'd expect performance with such high packet loss rates to be similarly bad.
As long as you're accessing sites on MCInet or anywhere else that does not require going through the MAE-West black hole, the Road Runner service performs nicely. Streamed audio sounds pretty good; I tried listening to 112 kb/s StreamWorks files from a site in Los Angeles and 40 kb/s Real Audio files from realaudio.com in Seattle and both sounded excellent, with few if any packet losses.
But the bottom line is that as long as the Internet path between Southwestern Cable and CERFnet passes through MAE-West, the San Diego Road Runner service is essentially useless for telecommuting. There is a chance of setting up a direct fiber link between Southwestern and either CERFnet or one of its major customers, and if this happens I will be able to recommend the service wholeheartedly.
On March 18, 1997 I noticed that the CERFnet/MCI path through MAE-West seemed much improved. The round-trip packet loss rate at about 3pm PST (normally the busiest time of the day) was only about 1%. This is a substantial improvement, but the cause is not clear. Nevertheless, the need remains for direct connections between Road Runner and the major local San Diego Internet sites. Even if MAE-West works well, it is inefficient to route local San Diego traffic such a distance.
Here are a few other miscellaneous idiosyncracies of the service. The IP addresses provided by DHCP in any particular part of the city are from one of four contiguous Class-C subnets, but the netmask provided by DHCP is 255.255.255.0. If you have a home LAN and Road Runner happens to assign addresses with a different third byte to machines on your network, they will be unable to talk to each other directly.
A related observation: Road Runner users are usually unable to talk to each other directly. Users in different regions appear to be able to talk to each other directly at the IP level (assuming they know each others' IP addresses), but users in the same region are not.
Because Road Runner is part of the external Internet, users accessing their employers' networks generally have to pass through a company firewall. This has been a significant issue in the past, but effective solutions are now available. The most expedient is the SSH package. SSH implements strong encryption and authentication above TCP. Three applications are provided: slogin, ssh, and scp. These correspond to the standard (but highly insecure) BSD Unix commands rlogin (remote login), rsh (remote command execution), and rcp (remote file copy).
On Unix and Windows, SSH also implements a nifty "TCP proxy forwarding" service. After a slogin session is established, SSH can accept an ordinary TCP connection on either end of the session and "tunnel" it across the encrypted link where it emerges as another ordinary TCP connection on the other side. This is primarily designed for X windows connections, for which it works extremely well. I've been using SSH for months between my BSDI (UNIX) system at home and my office Sparcstation running SunOS. I even use it on my home LAN; it's generally so fast that there's no real point in turning it off.
The SSH TCP proxy service is useful for gaining access to mail, netnews and web services inside a company firewall. You configure your local SSH client to accept connections to these ports on the local machine and automatically tunnel them to the servers you specify inside the firewall. You then configure Eudora, Netscape, Internet Explorer, etc, to use your local machine as its POP, SMTP, NNTP or HTTP server as appropriate.
The SSH client and server for UNIX and Linux is free GPL software. The SSH client for Windows 95 and the Mac are commercial programs; demo versions may be downloaded from http://www.datafellows.com. The windows version only provides the login client and TCP proxy services; it does not yet do scp or ssh.
A related problem is that the IP addresses provided by Road Runner belong to that service, not the company network. Furthermore, they are dynamically assigned by DHCP. This makes it difficult to run any kind of server that can be accessed by others, because the clients won't have any way of knowing your IP address.
These "alien" IP addresses (along with the firewall considerations mentioned above) also make it difficult to access internal company webservers.
One promising solution to this problem is Mobile IP, now being standardized within the IETF. (See RFC-2002.) This protocol is specifically designed to allow a computer with a temporary IP address from its service provider to use a permanent IP address on some other network. For example, a Road Runner user could use Mobile IP to make his server at home accessible by an IP address on the internal company network as well as by the temporary Road Runner IP address. Freely available implementations of Mobile IP are now starting to appear for UNIX, and we need to start experimenting with them.
I have used the tunnel driver in Linux to manually build this capability. It's a bit tricky, but it can be made to work.
A web client that uses a fixed internal company IP address could also access internal network services that grant access according to source IP address. But it would be much more convenient, as well as more secure, if the internal web services could be converted to use SSL (HTTP over the Secure Sockets Layer) so that they could be read from anywhere on the Internet as long as the user has the proper credentials. Since SSL automatically encrypts its data, internal web content would also be protected against interception -- which would not be the case if unencrypted Mobile IP were used to provide external access from employees' homes.
Until a better path can be established between Road Runner and Qualcomm's network, I am still using my existing ISDN line for traffic between Qualcomm and my house. Since I work mainly on my BSDI system, I have "dual-homed" it by adding a second Ethernet interface. The new interface connects to the Road Runner modem, while the old interface remains connected to the Ascend Pipeline 75. The default route points at the Road Runner service.
A dual-homed TCP/IP stack automatically uses the IP address of whatever interface is used to reach a given destination. So when I access Qualcomm I appear to be on the Qualcomm network (through my private subnet), and when I surf the outside net my machine appears to be on the San Diego Road Runner service.
Dual-homing creates another problem -- one I have not yet completely solved. While sites inside Qualcomm on the 129.46 subnet can connect to my home system using its Qualcomm subnet IP address with traffic passing over ISDN in both directions, sites outside Qualcomm cannot. Incoming packets do reach my machine through the Ascend ISDN router, but the reply packets follow the default route through the Road Runner modem. These packets carry the source address associated with Qualcomm, not Road Runner, and are for this reason are blocked by the Road Runner upstream firewall.
What is needed is a routing facility on the host that can make a decision based on the source address of the packet as well as the destination. But since the main reason to receive traffic from non-Qualcomm hosts is to receive email, I currently work around the problem by allowing my mail to relay through Qualcomm as I have qualcomm.com specified as a secondary MX (mail exchanger) host. When the sending site gives up trying to deliver the mail directly, it falls back to the secondary which in turn delivers the mail to me.
Nor have I found a totally satisfactory configuration for my other home systems, short of dual-homing them too -- which means buying a bunch more Ethernet cards and pulling more Ethernet wiring. If I want to transfer files between machines in my house I will manually connect them to my Qualcomm subnet; if I want high speed external Internet access I'll connect them to the Ethernet hub with the Road Runner modem.
And finally, dual-homing defeats a major justification for the $45/mo charge for Road Runner -- being able to offset the cost by disconnecting ISDN and saving $24.50/mo, plus my usual usage charges of $5-10/mo.
The Road Runner service was specifically designed to let the masses surf the World Wide Web at high speed. It actually seems to do this reasonably well, or at least it will once they improve their external connectivity. But it was clearly not designed to drop into a full-blown home LAN, especially one with a machine that acts as a server that must be accessible from the outside.
There are two general approaches to solving this problem. Times-Warner could enhance its system to handle traffic from employees wanting to reach corporate networks so that their service would more closely resemble the ISDN and dialup PPP services that we already provide for ourselves. Or we can do it ourselves by creating various "tunneling" mechanisms, wholly external to the Road Runner system, that would emulate what we want while appearing as a single ordinary user to the cable system (albeit one with somewhat greater traffic). Once the connectivity problem between Road Runner and CERFnet is solved, tunneling could solve nearly all of Road Runner's remaining quirks at the expense of some extra complexity on each end of the tunnel.
Still, the non-tunnel approach would be simpler, more efficient and elegant. But it depends on the assistance and good will of the cable company. They could easily get greedy and decide to charge whatever the market would bear for such "special features". In this case, we'd always have the tunnel approach to fall back on.
Phil Karn