Radio E-Mail in West Africa
Given these capabilities and limitations of HF, our design strategy for the project uses radio modems in a topology of field offices, as shown in the reference network of Figure 1. In Conakry we have a full-time internet gateway on the host coyah, and the radio modem on the host congo serves as the dial-in hub for each of the three field offices. We establish periodic PPP links between the field and Conakry and use our choice of carefully selected client/server protocols over TCP/IP. Although we might have implemented e-mail to the field using UUCP instead, our TCP/IP system is easier to configure and integrate with the existing network and e-mail system. This setup also is converted readily to use faster telecommunications linkups, such as land lines or satellites, if and when these become available in the field.
For now, though, we don't have the luxury of dedicating our radios to full-time connections for data communications. In fact, voice communication continues to be the central purpose of the radio equipment. Our implementation and procedures must supplement this lifeline, not impair it. Because data sessions over the radio block voice calls at each end of the link, we have policies and configurations to hold connections to less than 15 minutes per session to keep the radios free for voice contact. In the field, radio operators have procedural protocols for making their periodic “dial-up” connections with Conakry for e-mail exchange at regular intervals throughout the day. Radio operators adjust the schedule and break sessions as necessary to accommodate urgent voice communications. For these reasons, all dial-ups are necessarily under the control of the radio operators, rather than set up with cron jobs or diald.
The equipment used in this project is made by Codan, an Australian manufacturer. Although there are other manufacturers, including Motorola, Kenwood and Yaesu, Codan seems to be the radio of choice for international aid organizations in this part of the world. Their big white Land Cruisers with official markings have substantial Codan whip antennas bolted conspicuously to every front bumper. The symbolic authoritative value of these thick black whips, such as when crossing the many military checkpoints, is certainly their most dominant feature.
The modem used in this project is their 9002 model. These modems are equipped with a basic Hayes-like AT command set, so they are easy to configure, operate and troubleshoot with any telecommunications application.
There are some significant differences between this modem and the family Sportster, however. For one thing, the Codan unit actually is built as DTE (data terminal equipment) rather than DCE (data communication equipment). To connect it to your serial port, you will need a DB-9 null modem cable, wired as diagrammed in David Lawler's Text-Terminal-HOWTO (www.tldp.org/HOWTO/Text-Terminal-HOWTO.html). Not all cables described as null modem are wired the same, so this detail is crucial. Also, the AT commands are not as extensive as, and vary slightly from, the standard command set. And, of course, this modem moves data more slowly than you can possibly imagine.
The Conakry radio host congo, aliased as radiohub, is configured as a PPP server, ready to accept dial-in connections over the radio from offices in the field. As with a conventional telephone dial-in configuration, we use mgetty to watch the serial line, initialize the modem, wait for incoming calls, answer the “ring” and fire off the PPP dæmon.
The 9002 works pretty much as mgetty expects. We start by setting the modem to a known state with the factory defaults (AT&F) and then get defensively redundant. We set all command, local and remote echo off (E0 L0 R0); ignore carrier (X0); use hardware flow control (&K3); auto-answer off (S0=0 & A=0); and reset the station address (&I=nnnn, where nnnn is like a phone number, the unique identifier that other radios call to reach this particular station).
After mgetty answers the “ring” and gets a “connect” back from the the other end, then what? This is controlled by mgetty's login.conf file. It is common in dial-in systems to let mgetty look for incoming PPP packets and then start the PPP dæmon automagically, typically using CHAP in the link negotiation process for authentication. Such a configuration is handled by the line starting with the magic string /AutoPPP/.
In our experience, though, the high latency of the radio link makes an /AutoPPP/ configuration slow to kick in. What we do instead will be shocking: we dispense with conventional authentication entirely! In our configuration, the login name provided by the chat script of the incoming connection is used to start the PPP dæmon directly. When mgetty matches a login name with an entry in the first field of the login.conf file, such as Pklogin, it then runs the program specified in the fourth field, such as /usr/local/sbin/pppd.login.kenya. In essence, then, the login name used by the remote system serves to control access. Note that Pklogin is bogus as a system account, and you can be sure I haven't told you the string we are really using! (Note also that we have an implicit system of human authentication even before a connection is made, when operators agree by voice to lock on a specific channel before starting the link.)
When mgetty gets a login name listed in the login.conf file, it then passes control to the corresponding start-up script, such as pppd.login.kenya. This in turn starts the PPP dæmon, using an options file for the particular remote host, such as options.kenya.
To spare yourself bitter trials of sweat, tears and other emotional excretions, and pay attention to the lcp-restart and ipcp-restart options. These parameters give the time, in seconds, that pppd will wait to receive a reply to that particular phase of PPP negotiation before trying again. The default value of these parameters is three seconds, which is generally more than adequate when using regular telecommunications.
Over the radio, though, if these restart defaults are not extended, you'll only snag yourself a useless snarling hair ball. Here's what happens. As pppd starts up, each peer begins a negotiation process with the other to agree on all parameters for the connection. During these initial discussions, when one end of the link doesn't hear back from the other within its restart interval, pppd repeats the transmission. In the meantime, though, the remote end has received the original transmission and sends back its reply. The local end gets this response back to its first transmission, thinking it has a proper response to its second, and proceeds to the next step of negotiation. But then the local server gets what is now the unexpected response back from its second transmission, and the negotiations break down in unresolved chaos.
By extending the lcp-restart and ipcp-restart parameters, you can delay sending out repeat transmissions for a sufficient amount of time for the peers at each end to receive a response. We have configured a generous 16-second delay and have not had any more problems.
Turning our attention up-country, each remote host in the field is configured to dial up the radio server in Conakry. After all our testing, failures and ordeals of travel, it was a happy and amazing day when we finally got our first link across radio waves spreading invisibly through the Guinean atmosphere. From kenya we actually made SSH connections with congo simply to express our exuberance over “talk” sessions with the radio operators watching their terminal screen in Conakry—“Greetings from Kissi!”
With the configuration details finally worked out, we found that the PPP link, although slow, would come up reliably and remain stable at all times of the day, even over channels that otherwise sounded fuzzy and had considerable static. Of course, all radios and antennas should be tuned for their best performance. But once you are able to establish a link, it is reassuring to find that the radio modems are quite capable of maintaining it, even when conditions are less than optimal. Because somehow, conditions always have a way of being less than optimal.
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- The Ubuntu Conspiracy
- A First Look at IBM's New Linux Servers
- Vigilante Malware
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Libreboot on an X60, Part I: the Setup
- Vagrant Simplified
- System Status as SMS Text Messages
- Bluetooth Hacks
- Dealing with Boundary Issues
- Non-Linux FOSS: Code Your Way To Victory!