Metricom produces 900 MHz wireless modems (actually packet radios) that can communicate with each other, IP gateways and phone bridges, either directly or using its cellular-like network known as Ricochet. Until recently three models were produced, all looking approximately the same for a programmer, and all operated at modest speed approximately 28.8Kbps. Network and IP gateways to the Internet, operated by Metricom/Ricochet were deployed in some areas including San Francisco Bay Area. Modems mostly were used to access the Internet using Ricochet as an ISP, however a group of people at Stanford University used them for their own networking projects utilizing less known "starmode". Stuart Cheshire wrote a starmode radio IP (STRIP) driver for Linux that is now a part of "mainstream" kernel.
Recently a new modem model Ricochet GS was introduced, as well as faster network that is supposed to work with new modem, increasing the speed to 128Kbps. Another change that was made for new network was the model how the network was operated -- now multiple ISPs share the network, separately routing packets between their users and the rest of the Internet.
Later yet another device, Merlin for Ricochet, was made by Novatel Wireless. It's a PCMCIA card, compatible with other Ricochet modems. Merlin for Ricochet apparently has Novatel hardware and Metricom firmware, or at least this is what I can derive from messages that it produces and Novatel technical support responses that were very informative about hardware and absolutely uninformative about everything else.
No "official" support for non-Microsoft operating systems or starmode was announced by Metricom and Novatel, however after few changes in software and configuration used for old models I was able to fix whatever got broken, and now both Ricochet GS and Merlin for Ricochet work without problems on my Linux notebook.
Ricochet GS has two mutually exclusive interfaces to the computer -- serial and USB. Serial interface is exactly the same as with old modems (pins layout on the modem's connector is the same as on Ricochet SE), and it supports up to 115200bps, what is a bit less than modem's advertised transfer rate. With USB this limitation does not exist, and it was reported that Metricom engineers were able to achieve 256Kbps in the lab conditions, and 180Kbps was seen in San Diego service area. On the other hand, I have observed extremely low transfer rates (below 20Kbps) in some locations in San Francisco Bay Area, and 128Kbps in others, within few miles, and it looks like there were various problems in both Ricochet and WWC networks in first few months after introduction of 128Kbps service. Later problems were fixed, however I still see different results ranging from 30Kbps to 170Kbps depending on location.
This makes USB interface potentially significantly superior to serial, however it seems that at least in San Francisco Bay Area local conditions (probably configuration, location and type of retransmitters) often limit the transfer rates below the level where the difference is noticeable.
USB interface uses the same connector on the modem (this is probably why it has 14 pins) with USB cable. I was pleasantly surprised when I have discovered that USB interface uses "Abstract Control Model", and therefore is supported by existing USB moudem drivers, what happened to be already reported. I have found that the modem driver in Linux 2.2.16 backport and Linux 2.4.0 crash on STRIP driver's attempt to change the connection speed for "high" baud rates, however fortunately there is no need to change the baud rate in the first place, as USB interface doesn't really use it anyway.
Another noticeable change is in the modem's serial number format -- old modems had four digits, dash and four more digits, like "0002-0123", new ones have the same, prefixed by additional two digits and a dash, like "03-0002-0123". While harmless by itself, the change breaks STRIP's mapping of serial numbers to "ethernet" addresses, as the driver and utilities just use digits to form the last four bytes by reading the pairs of digits in hex (so number remains human-readable when it's displayed in, say, ARP table).
Merlin for Ricochet is a PCMCIA card, and it looks like a serial device except:
First difference doesn't cause any trouble for serial drivers, as they don't really expect any particular timing, however the second one makes existing Linux driver unusable because serial driver expects that it can empty the receive buffer on the device before filling up 512-bytes flip buffer. With Merlin for Ricochet it often isn't the case when PPP is used because when data arrives, it usually is packed in full buffers even if MTU is lower -- modem has no idea about PPP packets boundaries, and packs the data in whatever way it fills the buffers. A patch should be applied to suppport this device (see below). Number format is also different -- first block of digits has three, not two digits: "004-0002-0123". I have made a patch for STRIP driver to support this address format later than Ricochet GS support was added, so only newer versions of the patch suport it.
Merlin for Ricochet lacks any indicators that can be used to determine its status -- no LEDs, LCD or speaker, one has to talk to the modem through its serial port to get its status.
I am subscribed to the service, provided by WWC, so other providers may differ in some ways.
First change that I have noticed was that username and password were assigned to me -- while no explanation was given except that they are necessary for connection, my first guess was correct -- they use PAP authentication. What is more important about that, and never was explained (but still easy to guess), is that when LED on Ricochet GS modem changes its blinking color from green to yellow, user can't assume that things are already working -- it only means that connection is established, and he still can get "authentication rejected" response, or receive some meaningless garbage instead of LCP -- it happened to me in some first attempts to connect, then was automagically fixed never to be repeated, so I can only assume that ISP's routers didn't have the authentication information then even though modem was registered.
Second, "mandatory" options for PPP changed -- now Van Jacobson compression option is correctly reported (even though rejected in negotiation), so it's no longer necessary to set "novj". However now sending any default IP address causes the router to blindly accept it even if it has nothing to do with the routing in the rest of the network, so now one has to set "noipdefault" option.
Third, for unknown reasons, but most likely because of sloppy configuration, routers sometimes send to the users IGRP packets every five seconds over PPP link. It's safe to ignore them, and those packets can even be used as an indication that the link is up and running. I use rp3 utility that includes bandwidth graph screen, and packets show comb-like pattern on it when everything else is idle. IGRP packets were sent early when service first came up, then they disappeared at the same time when other problems were fixed, and later they appeared again when something wrong happened with the network, only to disappear again in few days. I think, it's safe to assume that when they appear it indicates that someone at WWC is having trouble configuring the routers properly, and other problems may happen at the same time.
Fourth difference only applies to Rcochet GS and Merlin for Ricochet devices subscribed for service after December 23 2000. Modem-to-modem connections of any kind over the Ricochet network don't work with them, however in close proximity they can talk to each other and other Ricochet modems. Please note that WWC and Novatel have nothing to do with this change -- it was done by Metricom who control the Ricochet network, not by ISPs or equipment manufacturers.
2.4.x kernel is now released with full USB support, so people who have it installed don't need to change anything to use Ricochet GS with USB.
Kernel 2.2.18 has USB support included, so I recommend everybody who uses earlier versions to upgrade at least to 2.2.18, and use its USB support unchanged.
Linux 2.2.x kernel versions earlier than 2.2.18 do
not support USB, however USB support for 2.4.x kernel is ported back to
2.2.x. When 2.2.17 was the latest 2/2/x version I used the
patch for 2.2.16 kernel modified to match 2.2.17 (linux-2.2.17-usb.patch), as
while changes themselves are compatible, the original patch
doesn't match with changed
Documentation/Configure.help file in 2.2.17.
Ricochet GS works with regular Linux serial driver (including regular serial port and multiport cards) without any problems. If both USB and serial ports are available, it makes more sense to use Ricochet GS with USB because of its higher speed.
Merlin for Ricochet is near unusable with regular serial driver in both unpatched Linux 2.2.x and 2.4.0-2.4.1 (I don't know if/when fix will be included in the official kernel -- at this moment the latest release is 2.4.1, and it needs linux-2.4.1-serial-flip.patch to work with Merlin for Ricochet. PCMCIA support in 2.2.x and 2.4.x recognizes Merlin for Ricochet as a serial card without any changes to drivers or configuration. More detailed description of this is at the page, made by Greg Pomerantz, who first encountered this problem.
With Ricochet GS there are two ways to do it -- with serial or with USB interface. Serial interface will work with standard Linux kernel, on all reasonable hardware, however USB is faster. Additional advantage of USB is with laptops -- most of recently made laptops have one builtin serial port (or even none), and one USB port, so if the user uses even one additional serial device, such as Palm PDA, serial console port, etc, the only way to use Ricochet modem is USB port.
With Merlin for Ricochet there isn't really any choice -- from kernel's point of view it's a serial device, and it works without any problem with kernel that is patched to support it.
pppd(8) should be started with options:
In the configuration used in Red Hat Linux all pppd options except
noipdefault are set automatically if
HARDFLOWCTL="yes" is set in
service is the interface name (such as
ppp0), and connect script is chat(8), passed directly as a
connect option to pppd(8). chat(8) script is the
same as with old modems, except, of course, the phone number --
Ricochet's 28.8Kbps service used 777, now
different providers use different phone numbers, WWC currently
uses 3333, so
chatscript file (Red Hat uses
/etc/sysconfig/network-scripts/chat-ppp0) should contain:
Everything is the same for serial and USB except the device
/dev/ttyS? for serial, and
/dev/ttyACM? for USB), and speed
(115200 for serial and anything for USB -- I use 19200 for
consistency with STRIP over USB).
Both Ricochet GS and Merlin for Ricochet are supported by the latest versions of my STRIP patches, however they WILL WORK ONLY IN CLOSE PROXIMITY, NOT OVER THE NETWORK OF RETRANSMITTERS if they were subscribed for service after December 23 2000. Metricom itself can easily fix this, they have merely configured their "nameservers" (internal servers that are responsible for configuration of theit network, not DNS servers) to disable modem to modem communication for all devices that are registered after that date, however I expect that it will take a lot of trouble to convince them to do it.
To accommodate short and both forms of long serial numbers I have changed the translation procedure that is used to convert text representation of the address to ethernet-like address and back. Since modems of different types can coexist on the same network, and one host may have different modems on multiple interfaces, changes keep the original behavior when only short serial numbers are used, providing interoperability with old modems and old drivers, and in mixed networks where both old and new modems are used provide distinction between all possible addresses. The compatibility chart is:
New driver converts long serial numbers in the same manner as old ones as if there was no 2-3 digits and a dash prefix, however prefix is used to fill additional bits that are always set to 0 for any short serial number. If prefix is two digits, it is used to fill bits 32-39, and if prefix is three digits, it is used to fill bits 32-43. Two last digits of the prefix are taken as hexadecimal representation of the byte, and that byte is copied into bits 32-39 inverted. If the prefix is three digits, the first digit is used to fill bits 40-43, also inverted.
Additional bits are inverted to accommodate all possible values of serial numbers. Since only digits 0-9 are allowed, each two-digits sequence can be anything between 00 and 99 (decimal). Ethernet address should unambiguously represent its corresponding serial number, so when conversion from ethernet to text is made, it should be clear if long or short serial number should be used. In the case when bits are not inverted, if the value of bits 32-43 is nonzero, it will be obvious that the serial number is long, however if those bits are all zero, it may be either short address, or long address with leading two or three zeroes. I don't know if Metricom will ever use 00 and 000 as a possible values for the prefix, yet if that will be the case, the conversion from ethernet address to text representation of the address will be ambiguous, and I have already found out that Metricom modems don't treat strings "000-nnnn-nnnn", "00-nnnn-nnnn" and "nnnn-nnnn" as equivalent addresses.
When inverted bits are used, ambiguity could happen if first two digits were "ff" or "fff", what is impossible because only digits 0-9 are allowed in serial numbers.
I could use bits 44-47 to indicate the length of the serial number, but it would unnecessarily pollute the address space and make future extensions impossible.
As I have mentioned, USB driver crashes on the attempt to change the speed on the fly, that strip driver uses to set values of 57600 and 115200. Until that will be fixed, obvious solution is not to use those values, as in USB mode the modem ignores them.
I have made patches for kernel against Linux 2.4.1 ( linux-2.4.1-strip.patch, should be applied against http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.1.tar.gz), and for net-tools http://www.tazenda.demon.co.uk/phil/net-tools/net-tools-1.57.tar.gz -- it's at net-tools-1.57-strip3.patch. net-tools 1.57 already have STRIP support, so this patch only changes the handling of addresses, in the same manner as it is done in the kernel patch. This patch is the later version of my previous net-tools-1.57-strip.patch patch -- original version did not support three-digits prefix, and second version only supported it one-way -- that was fixed by Kevin Brosius in August 2001, however I forgot about it and only posted in January 2002.
The information about STRIP use and configuration can be found on the original authors' page at Stanford.
I have made various tests that involved STRIP between old Ricochet SE and Ricochet GS, between multiple Ricochet GS modems, and between Ricochet GS and Merln for Ricochet. The result shown that Ricochet GS (that I have bought last year) can talk to all Ricochet modems in close proximity, and to all modems except Merlin for Ricochet (that I have bought this year) over the Ricochet network. Different service areas such as San Francisco/San Jose, New York and Denver, are connected, and latency for packets that pass between service areas is in the range of hundreds of milliseconds. Within one service area latency is 100-400ms, and in close proximity (when retransmitters are not involved) it's 100-200ms.
Disclaimer: The information in this document is the result of my tests and observations made at the time of writing, accuracy of it is not guaranteed. I am not affiliated with Metricom, Novatel, WWC, Stanford University or anyone/anything else mentioned. Reader is responsible for all his actions based on his use of this information. Trademarks are property of their owners. Linux kernel, net-tools and all patches for them mentioned here, are distributed under GNU Public License, unless stated otherwise in files. All patches inherit licenses of the patched files.