Radio E-mail in West Africa: The Complete Version
Given these capabilities and limitations of HF, our design strategy for the project uses radio modems in a topology among field offices, as shown in the reference network of Figure 1. In Conakry we have a full-time internet gateway on the host coyah. 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, our TCP/IP system is easier to configure and integrate with the existing network and e-mail system. This setup is also readily converted to use faster telecommunications linkups, such as through landlines or satellites. If and when these become available in the field (and as the budget may support them), the IRC network is ready to simply plug in.
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, providing an essential lifeline for the safety and security of field office and mobile unit personnel. Our implementation and procedures must supplement this lifeline, not impair it. Since 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. Otherwise, we 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. A schedule is established for these transfers, but radio operators still maintain the latitude to 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, as we might do in other, better connected circumstances.
The equipment used in this project is made by Codan, an Australian manufacturer of two-way radio hardware. 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. Wherever expats gather, you will see their big white Landcruisers with official markings and the substantial Codan whip antennas bolted conspicuously to every front bumper. While emphatically robust and utilitarian, the symbolic authoritative value of these thick black whips—such as when crossing the many and potentially intimidating military checkpoints—is certainly their most dominant feature.
The modem used in this project is the 9002 model. (Believe it or not, Codan also makes a 2400 baud fax modem, model 9001. We found a used one on the local market for $500.) These modems are equipped with a basic Hayes-like AT command set, so they are easy to configure, operate and trouble-shoot with any telecommunications application available for Linux, such as Minicom or Kermit.
There are some significant differences between this modem and that Sportster you may have jacked to your phone line, however. For one thing, the Codan unit is actually built as DTE (data terminal equipment), rather than DCE (data communication equipment). To connect it to your serial port, you need a special DB-9 null modem cable, wired exactly as diagrammed in David Lawler's “Text-Terminal-HOWTO”. Since not all cables described as null modem are wired the same, this detail is crucial. Also, the AT commands are not as extensive as, and vary slightly from, those you would expect to find on your standard USR model. And, of course, this modem moves data much more slowly than you can possibly imagine. The dripping of a famous-brand ketchup comes to mind, after refrigeration.
Returning to the network setup, 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 daemon.
The 9002 works pretty much as mgetty expects, and the sample mgetty.config file (Listing 1) shows how to do it. The comments in the listing describe the key settings. The most important line in this file is the modem initialization string given by the init-chat parameter. Here we start by setting the modem to a known state with the factory defaults (AT&F) and then get defensively redundant: 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 (Listing 2). It is common in dial-in systems to let mgetty look for incoming PPP packets and then start the PPP daemon 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. So 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 daemon 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 (Listing 3). This in turn starts the PPP daemon, using an options file for the particular remote host, such as options.kenya (Listing 4).
Here you may want to spare yourself bitter trails 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 and is probably why you have never encountered these options before now.
Over the radio, though, if these restart defaults are not extended, you'll only snag yourself a useless snarling hairball. 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 so 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 the repeat transmissions for a sufficient amount of time for the peers at each end to receive a response. Almost always the remote end will receive and reply to every original phase negotiation request, but the round-trip time can take several seconds. Here we have configured a generous 16 second delay and never have any more problems.
Turning our attention up-country, each remote host in the field is configured to dial-up the radio server in Conakry, using PPP configurations corresponding to those shown in Listings 5 - 8 for the kenya host in Kissidougou. These reflect the key configuration issues as already discussed for the server, such as the crucial modem initialization string (Listing 8) and the essential options for pppd (Listing 6).
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, just 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 the PPP link, although slow, would come up reliably and remain stable at all times of the day, even over channels which otherwise sounded fuzzy. Of course, all radios and antennas should be tuned for their best performance. But once you establish a link, it is reassuring to find 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.
- Red Hat OpenStack Platform
- Transitioning to Python 3
- Tech Tip: Really Simple HTTP Server with Python
- Stepping into Science
- Linux Journal December 2016
- CORSAIR's Carbide Air 740
- A Better Raspberry Pi Streaming Solution
- Custom checks and notifications for Nagios
- Radio Free Linux
- The Tiny Internet Project, Part II