Getting APRS Data to the Internet
Not to brag, but the path that APRS data takes to the internet after being plucked from the ether in Dayton is perhaps the most complex (or at least convoluted) of any aprsnet site.
The Miami Valley FM Association has a site just south of downtown Dayton at a municipal water tank (this is the Ohio equivalent of a mountain top). In addition to three voice repeaters (146.64, 146.91 -- which will soon support MIC-E -- and 444.25), the MVFMA has a Linux system serving as a multi-purpose AX.25 switch. Info on using Linux for packet radio is at www.febo.com/linux-ax25.
The Linux machine is connected to several radios, including a Motorola Mitrek on 144.39 with an antenna on the water tank about 120 feet above ground, and our 19.2kb packet repeater on 430.95 MHz. In addition to serving as a network node, this system serves two purposes for APRS: it provides a WIDE digi function (callsign W8APR), and it forwards all APRS traffic on 144.39 on the 19.2kbps UHF network. The software that does all this is described below.
The Current System
The APRS data currently follows the following route to get to your browser:1. The system at David Road is a Linux computer that runs, among other things, the "digi_NED" software that Henk de Groot wrote. digi_NED is set up to provide the WIDEN-N digi function we need (the W8APR digi), but also to dual-port digi all the APRS traffic from 144.39MHz to a high-speed UHF packet link that serves as a server backbone for our area. So, all the local APRS traffic is dumped to the UHF link.
2. Then, at my house another Linux system running Digi_NED is listening on the UHF channel. The Linux system is also running (among other things) the "aprsd" APRS internet server software. The digi_NED program here (callsign W8GPS) is used as a filter -- it passes only the APRS traffic on to the aprsd input, and ignores all the other traffic on the UHF channel. The link between digi_NED and aprsd is sort of a virtual or pseudo TNC within the Linux system; there's no physical wiring.
3. The aprsd software does two things: (a) it forwards the local traffic to the national APRS internet system by connecting to one of the main hub servers, and (b) it listens for incoming connections on the local ethernet.
4. The Linux computer that runs the dayton.aprs.net web site (as well as my other web sites, including the main one, www.febo.com) is connected via ethernet to the computer running aprsd. When someone connects to dayton.aprs.net and brings up the "javAPRS" page that provides the map, the web machine establishes a connection to the ham machine and starts copying the APRS data, which is then forwarded to the user's web browser. The connection to the Internet is currently a 64kb ISDN line; I'm hoping to upgrade that to something faster this fall. 5. If you're really into the geek stuff, there's one more trick involved. Java has a strong security model, and it will not allow an applet (like javAPRS) to input data from a machine different than the one hosting the applet. So, I can't just point the end user's browser to the ham machine for the data feed; javAPRS will refuse to look at data from that system. Instead, the web server runs a program called rinetd that acts sort of like a proxy -- when you run the javAPRS applet on your browser, it attempts to open the APRS data stream on a specific TCP port on the web machine. rinetd intercepts that request and opens up a connection to the ham machine, and then starts spitting the data out. So, the data looks like it's local to the web machine when in fact it's being piped in from the ham machine. That fools javAPRS into running.
The Old System
This is a description of the original setup that was used to route APRS data from David Road to the Internet. I'm keeping this here for historical interest.The Linux machine at the David Road site uses a program called aprsmon to to forward APRS data via TCP/IP on the UHF link. The other end of the UHF link is a system in N8UR's basement, running Linux and TNOS TCP/IP software, which routes the APRS data via ethernet to www.febo.com, which also lives in the basement. All told, one RF link, one slip link, and one ethernet link are needed to get the data from David Road to the web server.
A homebrew program on the dayton.aprs.net server (which is the same machine as www.febo.com and www.mvfma.org) spools the data to a disk file after adding some timestamps and other information. When your browser downloads and runs the javAPRS applet from here, it opens a TCP/IP connection to another homebrew program on the server which sends you the last 30 or so APRS packets stored in the spool file, and then continues to feed live data (in reality, delayed by a second or two due to the extra RF hop) that javAPRS displayes on your screen.
The key software is the "javAPRS" java applet and supporting files that Steve Dimse, K4HG, wrote. javAPRS, and information about how to configure it, is available from The APRSnet Home Page.
The software used on the W8APR digi to grab the APRS data is "aprsmon," written for Linux by Alan Crosswell, N2GYK. aprsmon is an internet server program that listens to a radio port on a Linux system and dumps the data to anyone who connects to the proper IP port (in our case, "14439"). aprsmon and its companion program "aprsdigi" (which provides the digipeater function for W8APR) are available from N2GYK's web site.
However, there is a complicating factor. For security reasons, javAPRS and your browser must think the APRS data is being generated on the same machine as the web server -- that's why most of the javAPRS pages are hosted at www.aprsnet.net; Steve has put together the tools to grab data from multiple sources, combine it, and serve it as a data stream for javAPRS applets downloaded from his site. Only madmen want to create their own javAPRS sites...
So, when we decided to create our own javAPRS site, we had to not only configure the javAPRS applet to provide the display we wanted (which was pretty straightforward), but also get the data to look like it was coming from the web server, when in reality it was three hops away at the MVFMA site.
To address the problem of running the web server and the radios on different machines, Alan Adamson, NE1H, wrote a "javaGate" shim that runs on the web server, connects to the aprsmon IP port of the machine with the radio, and forwards the data to the end user. Since the data appears to originate from the web server, the Java security concerns are met. javaGate is available from NE1H's web site.
The only drawback to javaGate is that it opens one connection from the web server to the radio system for every user running javAPRS. So, if we had three people accessing the data stream at once, three copies of every APRS packet would have to flow over the UHF link. In our situation, that causes a problem because the RF link between won't support the traffic that several users could generate. So, we've taken a slightly different tack.
I've written two simple perl scripts. Like javaGate, they run on the web server. One of them ("aprsbuf") connects to the aprsmon port on the Linux machine with the radio port, collects the data stream, adds some timestamps, and spools it to a disk file on the server. The other ("aprsfwd") is called by inetd every time someone tries to connect to port 14439 on the web server, and it sends the connecting program the last few lines of the spooled data and any new data that is appended to the spool file while the connection is open (it works much like "tail -f" on a Unix system).
The advantage of this configuration is that only one copy of the data needs to be sent over the RF link between the two machines, yet the web server can support a large number of users. I just finished hacking on these programs, so I don't feel comfortable posting them just yet. When they're debugged, I'll make them available here. In the meantime, if you have any questions about the setup here, drop me an email by clicking on the button below.
Copyright 1998 - 2001 by John Ackermann unless otherwise noted above.
See Copyright and Other Legal Stuff for more information.
/magic.html was last updated Saturday, 09-Jun-2001 09:30:17 EDT