Some AREDN progress

We have been working on bringing up an AREDN mesh network at ARRL HQ and here at AA6E.  AREDN, the Amateur Radio Emergency Data Network, has developed from the HSMM project (High Speed Multimedia, see web sites here and here.)  AREDN supports a "mesh network" running under FCC Part 97 (Amateur Radio) rules on allocated frequencies some of which are close to standard "WiFi" (2.4 and 5 GHz).

Ubiquity Nanostation Loco M5 AREDN node

What is mesh networking?  Simplified, it is a way to interconnect more or less randomly located network nodes that may come and go, such as in response to emergency requirements.  Each node may originate data or may relay data to adjacent nodes. Networking software automatically routes packets by the best paths through the mesh, from source to destination.  Certain mesh nodes may have gateways to other networks, such as the commercial Internet.  Certain nodes may have special servers (web, email, file, etc.) that are made available to the network.  In general, AREDN mesh networks are set up to be independent of commercial communications services as much as practical.

At AA6E and ARRL, we have implemented a test network to learn about AREDN technology and to try out configurations that might support a variety of routine and emergency communications needs.  The first setup uses up to 4 Ubiquiti NanoStation Loco M5 devices with custom AREDN software.  These form a small-scale mesh, currently all within the ARRL Laboratory.

A test bed setup at AA6E uses two of these nodes to demonstrate network capabilities.  Below is a block diagram of the tested network.

The AREDN network is at the right.  One Loco M5 device supports a laptop computer (where I am writing this article).  Through the radio link at 5.9 GHz, the two Locos support a bit stream of up to about 30 Mb/s using a 10 MHz RF channel.  As seen by the laptop, the Loco provides an IP address through its own DHCP server.  Traffic is routed to the second Loco, which in turn supports two VLANs (partitions of a single Ethernet connection).  One is a generic "LAN" connection that will support Ethernet devices like the Raspberry Pi which is acting as a small webserver for our test.  The Pi will also support SSH, VNC, and many other services as needed.

The second switch port supports another VLAN for "WAN" connections, e.g., to the Internet.  Through the Internet router it obtains an address on the household LAN.



L to R: Raspberry Pi 3; Netgear GS105E VLAN-aware switch; Toshiba Laptop

This setup demonstrates many of the functions we would need in an operational network.  We still need to set up facilities for node to node bridging that we would need to build up a larger network, supporting multiple operating bands, etc.

There is nothing "new" here.  It's all been done elsewhere, but we are climbing our learning curve.

More Network Fun: Asus, HP, and Xfinity

Asus RT-N66U (l), Cisco/Xfinity DPC3941T (r)

...in which we demote the Asus RT-N66U.

Faithful readers know about my efforts get reliable networking here at home (last post).  I want IPv6 to work well, and I'd like all my devices to freely work together, with good Internet access.

We took 2 steps forward, and then 1 back.  IPv6 worked, but not reliably when I set up the Cisco DPC3941T for "bridging mode" and gave the routing function to the Asus RT-N66U.  ICMPv6 packets were displaying lots of errors.

We ran the house that way for about a month.  Everybody was happy (in an IPv4 way), but there was one significant problem. Our HP LaserJet Pro MFP M127fw printer was not working reliably.

HP LaserJet Pro MFP M127fw

This is an "all in one" B&W laser printer / scanner / fax system offering lots of capability for a reasonable price.  It offers WiFi, Ethernet, or USB interfacing.

Everything works fine on Windows.  After a detour through HP's website, it works on Linux, too.  It works with Google's Cloud Print service, and HP's ePrint.

It worked for a while, but then would go catatonic and refuse new jobs after a period of minutes or hours.  You could always get it back by cycling the AC power.  We lived with this for some time, but it's pretty annoying to start a print job from the other end of the house, only to find out later that it did not go through.

So we tried a lot of tricks, adjusting the printer's setup, the router's setup, and even the Linux driver installation.  (The problem showed up with either Linux or Windows.)  We updated the printer's firmware. We tried both WiFi and Ethernet connections. 

Cut to the chase.  Eventually we cut out the Asus router, and there was progress.  Using the Cisco/Xfinity/Comcast router by itself, the printer worked -- and IPv6 worked, too!  It is clear that the Asus/Cisco combination (if not the Asus alone) is problematic for HP and IPv6.

So we retreat another half step.  We still use the Asus box as our main WiFi access point.  The Cisco 2.4 GHz WiFi transmitter is much weaker (nearly 20 dB weaker) that Asus, and it's built-in antenna system is doubtful.  (The Cisco box may actually be defective.)

For the moment, printing works, IPv6 works, and we will stop there.  The problems we had originally with Xfinity's DHCP and other issues of that sort are still there, but overall it's time to relax.

IPV6 ready

Comcast has blessed me with a working IPv6 connection, viz http://test-ipv6.com/:



What does it mean?  It means that we're all set when some of the Internet service providers are forced to use the new IPv6 addresses when there are really no IPv4 addresses left. (That's likely to begin soon.) It also means I'm behind the curve technically.  I understand IPv4, more or less, but v6 seems very different and a lot more complicated.

Comcast also upgraded us to 100 Mb/s download (from 50) without fanfare.  That's nice, but I'd rather have had a 50% price cut.

Internet Speed Tests

At AA6E, we are using the Comcast "Xfinity" "blast" service, which originally provided 50 Mb/s download, but now seems to have been quietly upgraded to ~100 Mb/s. Oh, we seem to have IPv6 service now, too.  Effectively using that in my home network will be a challenge. (One that I don't need at this time!)

Test with http://speedtest.comcast.net (MA server):

but Boston is not 5300 miles away!

Comcast (NJ Server):

Broadband Reports offers a more sober report http://www.dslreports.com/ (NJ):

The list price for this service is pretty steep IMO ($60/mo), but a slower service is not much cheaper.

Data Footprint Control -- Your own email server!

Lately I've been talking up the idea of "data footprint".  It's a fact that we're spreading all kinds of personal data around the Internet in the course of our modern electronic and financial lives.   Our bank, Facebook, Google, Yahoo, Comcast and essentially everyone we do business with is collecting data about us. The data get bought and sold and snooped no matter what our wishes may be.

One concrete thing I could do, while having a bit of fun, was to move my Google email back to a server computer under my own control.  That's (a) a rather old-fashioned thing to do, (b) rather complicated to set up correctly, and (c) a losing game in terms of functionality.  No doubt Google Mail sets the standard for usability, especially for power users.  It also has the best anti-spam technology I've come across.  So if we step back to a local server, we will be losing some useful features.

It happens I have an older Raspberry Pi (256 MB Model B) which hasn't had a particular mission.  So now it is the household IMAP server, with my 1.6 GB email stash on a 16 GB SD card.  It would have been easier to use a big PC for this function, but I wanted a platform that I could leave on 24/7 without eco-guilt.  It uses just a couple of watts of power.

I am temporarily (until I forget all the details) an expert on Postfix, Dovecot, and SSH, allowing me to access the e-mail from any machine on the home network and (securely) from external machines. Fortunately, I have an external SMTP relay that is part of my web hosting service, so outgoing e-mail should be treated with proper respect by the big services.  (A user PC directly sending out SMTP mail is often shunned as a likely source of spam.)

It's a just a symbolic step. We have a long way to go before we get control of all our data.

UPDATE 1: The dirty little secret they don't tell you at e-mail school is that most e-mail is spam, and an e-mail server without spam filtering is ... not worth a lot.  On the client side, Thunderbird and some others make a valiant attempt, but it wasn't going to work for me.  Especially since I want to use an Android client like Kaitin (no spam filtering) for mobile e-mailing.  So I consulted  https://help.ubuntu.com/community/PostfixAmavisNew. (Ubuntu is close enough to Raspian.) Everything installed OK until it became clear that my 256 MB Pi might not support a big freshclam update.  OK, we don't need antivirus for Linux/Android, do we?  Anyway, the server has started bouncing spam pretty well now.  And the Pi can feel virtuous as it crunches on each message for a second or two.

UPDATE 2:  ClamAV is hopeless, taking way too much RAM and CPU.  Fortunately Amavis doesn't need antivirus, so it's OK just to remove it from the system.  Even so, Amavis & co. take a lot of RAM and just fit in the 256 MB machine along with Linux.  If I start doing package updates, for example, there is a lot of "disk" thrashing -- swap utilization climbs, and things go very slow for a while.  (But no crashes!) A 512 MB machine would be much better.  Spam scanning and message handling seem to take 5 to 15 seconds per message.  This is not a high volume solution, but it handles my load OK.

UPDATE 3: This project was a success technically, but Comcast woke up to it (maybe they read my blog?) and they blocked port 25 on my service. Maybe I could have argued my case, but I didn't pursue it. Instead, I moved my email action to Pobox.com, a commercial outfit that specializes in email - and doesn't sell my info to the highest bidder, hopefully.

Adventures in Platform Independence

So I have this nice program developed that will allow us to transmit compressed communications audio over an Internet link.  It will be part of a remote Internet receiver that will support W1HQ, the club station at ARRL, Newington, CT.

The program came together fairly easily, using old-fashioned Linux / C programming, together with the Speex and Portaudio libraries.  The sending program runs on an ARM-based Beagleboard card, and the receiving side should run on any Linux box running Ubuntu or your favorite Linux distro.

Along with the audio software, there is an independent rig control function using Python, wxWidgets, and Hamlib.  That should run nicely on Linux, Windows, or what-have-you.

Since our W1HQ crew really needs to keep their Windows station computer, we do need to make the audio receive software run under Windows, along with rig control.  That's where today's lesson begins.

Porting to Windows!

The problem of porting Linux C code to Windows is the subject of a lot of Internet discussion.  It needs to be done frequently, but the process is not simple.  For one thing, the programming tools are rather different.  While the basic principles are the same, all the details are different.  In Windows you generally code within a complex IDE system (Interactive Development Environment).  Managing libraries, dealing with the graphic user interface, and even finding useful "help" files are all a challenge. But the killer, for me, is the unavoidable fact that the underlying operating system just does things differently from Linux.  This shows up in many ways, but my problem specifically was dealing with Internet communications (sockets).

I looked at 3 approaches, before finding a solution that might work for us:

1. Visual C++ and Visual Studio.  This is Microsoft's preferred development system, using the big IDE model.  Fortunately, there is a free "express" version that might work for us.  I could get the Portaudio and Speex libraries to compile, but the socket programming model seems to require serious recoding work.  It would be possible, but it's almost like starting from scratch.  Furthermore, we'd end up with  Windows source code and Linux source code that would have to be maintained in parallel.
2. Cygwin.  Cygwin is software that runs under Windows and provides a Linux command line interface.  Compiling with gcc works in Linux style, so that's good.  However, there is no support for Linux sockets model, so it's no help in the end.
3. MinGW.  MinGW does not provide a full Linux run environment, but it has a number of features that help you compile Linux code to run under Windows.  Compiling the libraries is no problem, but still there is no sockets compatibility.

Not Porting to Windows!

The only solution I've found that won't require investing time in Windows C programming, is to virtualize the problem.  That is, set up a virtual Linux PC inside our Windows box using the free Oracle VirtualBox.  A good modern PC should have enough horsepower for this.  (We'll see about the W1HQ machine!)  Once this is set up, you can run all the code the way it was meant to be run.  The price to be paid is 4-8 GB of disk space and 300-500 MB of RAM.  Since our needs on the Linux side are very modest, we may be able to pare down the memory requirements substantially.

VirtualBox runs the audio software fine under Windows 7 on my home machine.

Update 9/8/2012:  VirtualBox works nicely, but it has a large footprint on any average size computer, so it's probably too much to run at W1HQ without an upgrade.  RAM upgrades are cheap, but it's probably worth another look at Windows coding.  I've simplified the audio transport to use UDP, so there's probably less OS dependency.  We'll see.

Uverse vs 80 meters

So, we've finally got to the point of some stability with Uverse in the house for TV, Internet, and telephone service.  That is, without doing much ham radio.

I discovered a nice tool, U-Verse Realtime, which lets you show many parameters of your Uverse operation. It's free software for Windows machines, and it seems to work in my virtual Windows XP machine.  (VMware under Ubuntu Linux.)

The first bit of science is to measure my "bitloading".  That shows what parts of the frequency spectrum are being used for the underlying DSL connection.  The results:

The chart shows that frequencies between about 100 kHz and 3.7 MHz are used for download (yellow), while 3.7 - 5.0 MHz are used for upload (green).  There is a small higher region, about 5.3 - 5.5 MHz also allocated to download.

The increasing line attenuation with frequency is apparent.  (At least, if you believe that "bitload" has something to do with signal power.  I don't really know that.)  The electrically measured line length from the Uverse node is 2554 feet, which puts me in the lowest of 3 service tiers.

OK, second science test.  The active DSL spectrum includes the 80 and 160 M ham bands.  What's the interference potential?  This is not a simple question.  The interference from Uverse's DSL connection might not be much of a problem.  Why?  The received signal is going to be weak (indicated line attenuation is 21.6 dB.) The locally stronger transmitted signal, 3.7 - 5.0 MHz, is mostly outside the 80 M band, although there could be problems between 3.7 and 4.0 MHz, in the SSB band.  Fortunately (?), the 80 M band is naturally so noisy that the interference might not be noticeable.

The thing to worry about, I think, is interference to Uverse service.  I ran a very short test at ~3536 kHz CW.  I was downloading a large file over the Internet and listening to an HDTV program in the other room.  Transmitting with ~90 W output caused no apparent problems.  Transmitting at ~850 W killed the DSL connection pretty quickly.  Download stopped, and the TV image froze. It took about 70 seconds to reacquire the signal after transmission stopped.  (At least nothing was destroyed!)

This is all very preliminary.  We will need to improve the wiring and experiment with ferrite chokes -- probably on the incoming DSL connection.  There is no guarantee that kilowatt 80/160 M operation will ever work, but it might...

Uverse - First Impressions

Image by doegox via Flickr
As noted in the prior post, we are switching to AT&T Uverse.  Formerly, we had Comcast cable for TV, AT&T DSL (6 Mb/s) for Internet, and plain old telephone service (POTS) from AT&T.  Now we get all 3 services from Uverse - the so-called triple play.  Voice is now VOIP carried over the underlying DSL technology.

The installation went very smoothly, and the technician was not too fazed by my 1 KW ham transmitter or my Linux-based household network. (Of course, he didn't guarantee how well things would work in an intense RF environment.)

It turns out our distance from the neighborhood node is 2,554 feet. (This is FTTN service - fiber to the node.) By phone, AT&T had quoted ~750 feet from their not-too-accurate database estimate.  The service limit is 3,500 feet, according to our tech.  Our airline distance may be 750 ft, but our lines don't go direct.  This matters, because the ultimate data rate declines with increasing cable length.  We have ended up in the bottom tier of service, sigh.  This limits the number of TV channels that can be recorded or viewed simultaneously.  That's probably OK for us, but Internet service will be capped at 12 Mb/s for the foreseeable future.  Having double our previous speed is good, but eventually 12 Mb/s may feel too slow.  (Meanwhile, Comcast is saying 100 Mb/s service is coming.  No mention of cost.)

Preliminary observations: Everything works.  That's very good - much better than our early struggle with DSL.  We get a real 11+ Mb/s of data download.  TV works, but somehow the order was bungled and we do not have HD service yet.  A little worrying, the picture on SD TV is rather softer than we had with Comcast.  That probably reflects excessive compression by AT&T.  I wonder how much better HD will be.

Phone service by VOIP works nominally, but now we rely on a UPS to keep service up in a power failure.  POTS emergency service was much superior!
The level of system integration and the TV user interface is much better than what we had before.  Of course, Comcast also offers the triple play, but their HD video recorder system (and its control options) was inferior.  AT&T's services available through the TV are very interesting - receiving your phone voicemail?  I haven't tried that yet.

The industry has still not solved the command and control problem for home entertainment systems.  Even with the new system, we are in remote control hell if we ever want to use our DVD or other add-ons.  This is particularly frustrating for the less technical members of the household!  Why this could not have been resolved by now with some kind of standardized control bus among "home theatre" devices is not clear to me.  No one seems to take this major consumer interest very seriously.

Stand by for occasional further reports.

Update:  A few worrisome but non-fatal issues emerging.  Uverse VOIP service gives too many "fast busy" signals when calling some "well known" local numbers -- and even when calling Uverse support!  You would think "the phone company" would understand phone technology, even if it's VOIP.  This is a problem that almost never happened with the POTS network.

On the TV side, accessing some Uverse help files (apparently a TCP/IP web transaction?) return a 404 Page Not Found screen, which should never happen.  A while later, the request worked correctly.

Wondering about AMPRnet

Do you know about AMPRnet? I've wondered about this mythical network off and on since the 1980's packet boom. Back then, I was doing 1200 bps 2-meter packet from my home in Guilford, CT. I had a nice little setup with a toaster-style Macintosh, a KAM+, and a 10-20 Watt transmitter (Handytalky with an amp.). It would do the usual packet thing -- access local BBSs, digipeaters, etc. With a lot of effort, I could connect through RF gateways into New York or the Boston area. It was kind of fun sitting there and listening to each packet going out and (hopefully) returning. Not useful, by any means, but entertaining.

Then I got the TCP/IP bug. On the one hand, this was a loser for performance, adding all the overhead of full routing to each packet. On the other hand, there was a degree of error control, and I had actual IP addresses assigned to me! I was 44.88.4.9 (aa6e.ampr.org) and 44.88.4.10 (aa6e-1.ampr.org). So far as I know, the IPs are still "mine", but the server ampr.org has forgotten about me. :-(

There is a "Class A" network assignment for AMPRnet or "ampr.org" -- 44.0.0.0, or as we now say in CIDR terms, 44/8. That's a big deal. That is an allocation of 2**24 = 16,777,216 individual IP addresses, about 1/256 of the entire IPv4 address space, assigned to Amateur Radio. That's the same IPv4 address space that is supposed to be exhausted as soon as 2011.

AMPRnet appears to be very lightly administered (and that's being polite) -- even for an amateur radio activity. The allocations are supposed to be managed by regional volunteers, but coverage seems spotty. The advertised coordinator for my area seems to be inactive now, so there is no one for me to even ask about my allocation! And, if you can get a number, it doesn't have much value, since no one can route packets to you unless you make "upstream" arrangements that are impractical for individuals. People seem to set up tunnels to a server at ucsd.edu, which probably works, but is hardly the way to build a big network!

Traditional packet radio has been in long decline, except for special uses like APRS and DX spotting. Newer digital developments, such as DSTAR and HSMM use TCP/IP technology, since it's still the standard for computer networking, and they may use AMPRnet addresses.

What about that 44/8 network? Is there any way, other than history, to justify maintaining that huge allocation in the face of a global IPv4 number shortage? I know of no simple way to find out which ones are allocated. I would be surprised if there were as many as 1,000 in use. Out of 16 million, it's a trivial number.

The simple fact is that amateurs got a Class A allocation in 1992, when people weren't asking many questions and commercial use of the Internet was just beginning. We'd never get it today.

We should ask why amateurs actually want any IP number assignments. Wouldn't we do just as well with a non-routable private network like 10/8? The vision that somehow a random Internet user needs to interact with a random Amateur Radio station is an odd one. If it involves RF transmission, only licensed operators are allowed -- although the status of server based systems like e-mail and the web may be unclear. It's 2010, and we have 20 years of Internet and ham radio development to look back on. Ham digital nets are fragmented and don't talk to each other much, let alone the Internet as a whole. Why do we need full routability between the RF world and the Internet?

The Internet <--> ham model that is working is tunneling through the Internet to interconnect radio devices and computers. Echolink, IRLP, and DSTAR rely on this mode. No permanent ampr.org addresses are required. An RF-to-Internet gateway is generally at someone's house or place of work, where there is a standard Internet Service Provider connection. The gateway relies on the ISP's assigned address, just as we all do for domestic service.

So maybe AMPRnet needs to be put to rest, giving its water back to the tribe. That would make a nice press release: Public-spirited amateur radio operators help the Internet put off catastrophe for 2 months!

Or, maybe I'm missing something important. Let me know in the comments!

Jeff, WA4ZKO, has some good comments here and here.

A "perfect" gadget

This is an Encore ENRXWI-G "Wireless LAN Extender". I needed to extend my home Ethernet into the basement, for a project I'll describe later. For about $30 (newegg.com), this box saves me an hour or two struggling in my crawlspace for CAT 5 installation. That's a fair trade, I'd say! I bought two of them, with one as a spare.

In addition, it turns out this is a Linux box. (If you're up to it, you can reverse engineer the system and flash it with your own OS. But I will let that exciting project go for now...) And it can actually be used as a full-blown WiFi access point and in a couple of other modes. The only limitation is its single 10/100 baseT Ethernet connection.

I did try the "Repeater" mode with the second unit. Maybe this would help me get a better signal to the basement ENRXWI-G? My main WiFi access point happens to throw a shadow into the basement area that I am using, probably because of an intervening brick chimney. Moving my AP a foot or two seems to cure the problem, but could the repeater function do the same? I set it up according to instructions, and it seemed to help on the basement-to-AP route, but if anything hurt the performance (lost packets, etc) AP-to-basement. (puzzling) In any case, no joy.

A WiFi repeater is probably more appropriate when your client and AP are truly separated by long distances, and the signal strength directly from client to AP is really weak. The AP-to-basement path here is relatively short. My transmission errors may be due more to multipath reflections than to weak signals.

The only downside of this box, shared with most WiFi devices, is that there is a lot of setup required. The supplied documentation is about average, but many people will scratch their heads at some point when setting things up.

In summary, score one for cheap Internet appliances.

Is Ham Radio like a Telco?

Thanks to Slashdot for the following provocative video link. Van Johnson talks to Google about what comes after the TCP/IP Internet. In a nutshell, we have seen telco-style circuit switching morph into the current TCP/IP packet switched network, and the goal has always been to support end-to-end conversations. But the current Internet is dominated by fetching data (e.g. web pages), and TCP/IP is poorly suited for it. What will come next?



This talk leads me to ask what is "amateur radio" all about? Is it a way of supporting conversations? Of course, but is it more than that? Are we stuck in the telco model, a 100 year old paradigm? It is a problem if we are a hobby that only cares about "the wires" - or the airwaves -- and not about any higher level functionality. Food for thought.