Although Road Runner officially supports only Windows 95 and the Macintosh, it can be used with Linux. The installation is not yet plug-and-play, but if you're reasonably knowledgeable with shell programming and with TCP/IP networking under Linux you should be able to make it work.
At a minimum you must configure dhcpcd for your Road Runner interface, and you must download, compile and install my Road Runner login program, rrlogin.c. But there are some bugs in standard dhcpcd and in the Linux kernel that cause problems on systems connected to both Road Runner and to a local network, and I recommend installing the fixes described here.
While this document is specifically about Linux (more specifically the Debian Linux distribution) it generally applies to other UNIX-like systems as well. Non-Linux UNIX systems (e.g., SCO, FreeBSD, NetBSD, BSDI) may have slightly different routing commands. The details of any tunneling and NAT (IP masquerading) facilities may also vary.
If you're an @Home user, this document is not for you. It is wholly devoted to dealing with the brain damage unique to Road Runner (dynamic addressing and the login protocol) that is absent from @Home. Count yourself extremely lucky. You may wish to look at my companion paper on IP-in-IP tunneling.
Road Runner uses DHCP to assign your system an IP address, a subnet mask, a default router and a domain name system (DNS) server. The IP addresses are assigned from Road Runner's own address space (204.210.0-63.xxx in San Diego). DHCP-issued IP addresses are leased, that is, they are only temporary. The RR DHCP server issues leases for 3600 seconds (1 hr) but they may typically be renewed indefinitely as long as your machine stays up. Occasionally during system maintenance, Road Runner will restart their DHCP servers and force your system to accept a new IP address.
It is vital that all Road Runner users run a DHCP client daemon whenever they are active. Some Linux users report that they can bring up DHCP, get an IP address, kill the DHCP daemon and continue using the same IP address indefinitely. This is a very bad idea! Using an IP address beyond the expiration of its lease violates the DHCP model. If the RR DHCP server reassigns what it thinks is an idle IP address to another user, the resulting conflict can knock either or both of you off the net.
You can get away with it for a time only because most DHCP implementations check the addresses they're assigned by first trying to ARP for them. If the other user gets a response, it refuses the address assignment and asks for a new one. So if you "squat" on an IP address you may remain safe as long as you stay up to answer ARP requests. But if you go down -- even for a short time -- come back up and try to use the same IP address, it may already be in use by another user.
This vulnerability is surprising given how easily it could be solved with IP address filtering, especially given the paranoid firewalling elsewhere in the RR system. But as long as the problem exists, it is vital that Linux users not provoke RR management into an anti-Linux/UNIX crusade!
A DHCP implementation by Yoichi Hariguchi is already widely distributed with Linux, but I have made several changes to Yoichi's code that are especially useful with Road Runner. Since the the startup shell scripts I give later depend on these enhancements, I strongly recommend that you install my version, dhcpcd-0.70-karn.tar.gz.
Place this archive wherever you install source code, e.g., /usr/local/pkg, build and install it:
$ cd /usr/local/pkg $ tar xzvf dhcpcd-0.70-karn.tar.gz [...] $ cd dhcpcd-0.70-karn $ make [...] $ su # mv /usr/sbin/dhcpcd /usr/sbin/dhcpcd.old # make install
See the README and Changes file in the distribution for details on installation and on my changes, respectively. I have submitted my changes to Yoichi and hope they will appear as part of some future standard distribution.
If you have already installed the stock dhcpcd on your system, you will have a script in /etc/init.d/dhcpc that starts it up at boot time. Find the line that starts the daemon; on a Debian Linux system it will look something like this:
start-stop-daemon --start --verbose --exec $DAEMON -- $IFACE
and change it to look like this:
start-stop-daemon --start --verbose --exec $DAEMON -- -c /etc/dhcpsetup $IFACE
The idea is to have dhcpcd run the shell script
/etc/dhcpsetup (which we'll create later) when it successfully
obtains an IP address from Road Runner. Note also that $IFACE
must be set at the top of the script to the name of the
Ethernet interface that's connected to the Road Runner modem.
For reference, here's /etc/init.d/dhcpc as it exists on my system. I understand non-Debian versions of Linux may have a different startup script mechanism; you're on your own.
The 2.0.x Linux kernels have a bug that appears whenever dhcpcd is run on a system with more than one Ethernet interface (real or virtual). When dhcpcd requests an address, it temporarily sets the interface IP address to 0.0.0.0. Because of the kernel bug, this also disables any other Ethernet interfaces on the system. When dhcpcd successfully binds to an address, the other interfaces start working again. Normally, the outage is short so it may go unnoticed. But if Road Runner goes down, your system can remain completely unresponsive to the net -- even from your in-house LAN.
The interfaces actually continue to work during the DHCP binding phase, but they put an incorrect Ethernet address -- that of the sending interface -- in the destination field of all transmitted packets. (More specifically, the bug breaks ARP). The intended receivers never see them, because they're filtered out by the receiving Ethernet interface.
Here are my source patches for kernel version 2.0.33 that fix this bug. It has no known ill side effects, so there should be no problem applying this to all your kernels until it appears in some future official kernel release.
These patches modify files net/ipv4/devinet.c and net/ipv4/ip_input.c. To install them and build a new kernel, place the patch file in /usr/src/linux (or wherever you keep the Linux kernel source code) and say, e.g.,
$ su # cd /usr/src/linux # patch < kpatch # make # make bzlilo # reboot
You should examine the output of the patch step to ensure that they were made correctly before you proceed to build a new kernel.
The Road Runner login protocol is of course unique to Road Runner. It's on the floppy you get at install time, and versions are officially available only for W95 and the Macintosh. In fact, there are several different Road Runner login protocols; the one we use in San Diego was developed by Toshiba.
While DHCP is a fairly stable, reliable and well-documented Internet standard protocol, the same can hardly be said for the proprietary Road Runner Login Protocol developed by Toshiba. It is not publicly documented and has inherent flaws and deadlocks. They have been alleviated (but not eliminated) by a series of ad-hoc changes to timer parameters. Yet it still serves no discernable purpose other than to complicate the user's life and to generate lots of calls to technical support. Road Runner management has stubbornly refused to get rid of it, however, so we're stuck with emulating it under Linux. We still have to "log in" before Road Runner will accept your upstream packets.
To install, fetch my rrlogin.c into a local source directory, e.g., /usr/local/src, and say:
$ cd /usr/local/src $ cc -o rrlogin rrlogin.c $ su # mv rrlogin /usr/local/sbinrrlogin takes two command-line arguments: your Road Runner login name and password, in that order. If you don't provide these on the command line, rrlogin will prompt for them interactively but this feature is not particularly useful to us since we're going to invoke rrlogin from a boot script. Unlike dhcpcd, rrlogin need not run as root, but doing so causes no harm.
The rrlogin program has several other command-line options, but none are necessary for normal use. See the source for details.
The details of /etc/dhcpsetup depend on your specific system and network configuration, so you'll have to be flexible. This is where you can modify the routing configuration given to you by DHCP, e.g., if you use IP-in-IP encapsulating tunnels. This script must also start the rrlogin program.
PATH=/bin:/sbin:/usr/local/sbin if [ -f /var/run/rrlogin.pid ] then kill `cat /var/run/rrlogin.pid` rm /var/run/rrlogin.pid fi rrlogin rr_login_name rr_passwordYou must, of course, substitute your actual RR login name and password in the last line, and make sure the script is executable:
$ chmod +x /etc/dhcpsetupIf you now reboot your system, it should automatically come up on Road Runner, obtain an IP address, log you in and keep you there.
Note that you must have built your Linux kernel with this feature enabled. When running make menuconfig, go into Networking Options and select "Network firewalls", "IP: firewalling", and "IP: masquerading". You should also select "IP: ICMP masquerading". (IP masquerading is implemented as a hack on top of IP firewalling. This is why you must select firewalling).
But tunneling requires a "tunnel machine" with a fixed IP address on a nearby "friendly" remote network. The tunnel machine can be another Linux system, or a router that supports IP protocol 4 (IP-in-IP encapsulation -- not to be confused with IP version 4.) Almost all of your packets -- coming and going -- will be tunneled through this machine, so your network service is likely to be somewhat slower and potentially less reliable. If the remote tunnel machine and/or your network path to it goes down, you're off the air.
Also, setting up a tunnel is considerably more complicated and site-specific than masquerading, so you really need a good working knowledge of Internet routing and protocol layering. In a follow-on paper I describe my own setup along with the gotchas and caveats I've discovered; use it at your own risk. Also, please understand that I cannot offer the use of my tunnel machine to users outside Qualcomm.
Last modified: 18 Feb 1998