UPDATE (9/16/2014): I encourage people to read Bruce Schneier’s post regarding surreptitious tampering of computer chips, which includes hardware random number generators. It’s nearly impossible to know that a hardware RNG hasn’t been tampered with at the time of manufacture to facilitate a backdoor. Therefore, it might be worth sticking with a software RNG, as is the default behavior in Raspbian.
The Broadcom System on a Chip (SoC) in the Raspberry Pi features a hardware random number generator that can be used as a high-quality source of random numbers. This might be worth enabling if you’re using OLSRD in a secure mode. The secure mode causes the node to exchange cryptographic messages with other nodes in the mesh network. Strong cryptography benefits greatly from the use of a high quality random number generator. Also, the system load should decrease since the task of producing random numbers is offloaded to a dedicated hardware device.
Here’s a link to a quick how-to with the steps for enabling the hardware random number generator on the Raspberry Pi:
UPDATE (2013/09/02): I found that the wireless adapters were no longer able to run in Ad-Hoc mode due to recent changes to support the Beaglebone Black device. The installation steps on the Github project page have been updated to specify a commit tag (v0.2.0) when checking out the HSMM-Pi project to ensure you’re getting a stable copy of the code.
My initial recommendation for USB WiFi adapters was an inexpensive model that could be found on Amazon for about $7. They worked fairly well initially, but in the last week I’ve been unable to get the 3 that I own to work at all. I am no longer recommending them for use with Raspberry Pi models because of their instability.
I purchased the USB WiFi adapter sold by Adafruit which is advertised as being compatible with the Raspberry Pi. These adapters work flawlessly, and use a different chipset from the model I recommended earlier. The Adafruit adapter costs about $11 and does not accommodate an external antenna; but these negatives are offset by the adapter being stable.
My apologies to anyone who has had problems with the Amazon no-name adapter. And it would be great to hear from anyone who has had problems but managed to get the adapters to be stable.
I’ve been very pleased with the performance and support for the HSMM-Pi project on the Raspberry Pi platform, but have been curious to know how well it would work on other platforms. I received my Beaglebone Black (BBB) board in the mail on Friday and didn’t waste any time installing Ubuntu on it. The BBB is a small single-board computer similar to the Raspberry Pi. One of the compelling features of the BBB is that it has 2GB of onboard flash memory in addition to the memory card slot. I can see this bringing the cost and complexity down in an installation with several BBB nodes. You can install and run the OS from the onboard flash memory which is much faster than the SD memory card. It’s also easy to reflash the OS onto a BBB node; just pop in a memory card with the OS, hold down the Boot button while applying power, and the BBB gets re-flashed. It’s also got a 1GHZ ARM processor that is noticeably faster in comparison to the Raspberry Pi. And being priced at $45, it will be a strong competitor with the $35 version B Raspberry Pi. Lastly, the ARM processor features an open-source design that is preferable to the closed design of the Broadcom processor used on the Raspberry Pi.
I installed the Ubuntu 13.04 flash image dated 2013-08-24. The installation was pretty straightforward: write the image to an SD card, insert the card into the unpowered BBB, hold down the boot button on the BBB, apply power, then wait till the 4 surface-mounted LEDS are lit.
Once Ubuntu was installed, I SSH’d into the BBB and began installing HSMM-Pi. This was the first time I’ve tried the installation of HSMM-Pi on a clean Ubuntu system other than the Rasbian distribution meant for the Raspberry Pi. I encountered a few surprises:
- The chkconfig utility to enable/disable system services is not available on Ubuntu 13.04. The sys4-rc-conf program should be used instead.
- The make utility for processing Makefiles is not installed by default. That was a shocker.
- There was one spot in the install script where the ‘pi’ user account was referenced, but that account is obviously not present in a non-Raspbian distribution.
- The Beaglebone uses the ARM CPU architecture which supports position-independent code (PIC). The OLSRD codebase generated some compilation errors related to the use of PIC. I resolved this by changing the OLSRD build steps in the HSMM-Pi install script to pass the -fPIC flag to gcc while compiling.
- Must include an explicit ‘auto eth0’ statement in the network interface configuration file to ensure that the Ethernet adapter starts automatically on boot.
- The resolv.conf file is actually a symbolic link to a file in the /run ditectory. The link had to be replaced with a regular file that could be managed by HSMM-Pi.
I have corrected all of these issues in the ‘install.sh’ script that is checked into the HSMM-Pi Github repository. This means that HSMM-Pi is available for use with:
- Raspberry Pi nodes running Rasbian (based on Ubuntu 12.04)
- Beaglebone Black nodes running Ubuntu 13.04
This is great news for HSMM, as well as the HSMM-Pi project. More device platforms and versions of the Ubuntu OS should give people more options for building HSMM mesh nodes with versions of Linux that will be supported well into the future.
Here’s an interesting video about the design challenges associated with dissent networks built using mesh networks. Dissent networks are usually built using a mesh networks, and are often built in response to the censoring or limiting of Internet access by oppressive governments (think Egypt during the Arab Spring protests in 2011). The video suggests that there’s no silver bullet for building a mesh network that’s difficult to disrupt while also providing good performance. For example, using directional antennas improves signal range and reception, but it also makes the network more conspicuous and easier to trace; on the other hand, using omnidirectional antennas leads to a more robust network that is harder to jam, but it also leads to a lot more transmission collisions that decrease the network efficiency.
Last week I received an excellent suggestion from Drew Wood/KF5MMW to have a GPS-equipped HSMM-Pi node serve as a network time server (NTP server) on the mesh network. The GPS signal includes high-precision date/time information, in addition to the geographic location data we’re all familiar with. The HSMM-Pi mesh node runs a daemon called ‘gpsd’ when configured to use a GPS device for location info. The ‘gpsd’ service can provide time information to the ‘ntpd’ daemon that runs on all mesh nodes. The ‘ntpd’ daemon is responsible for keeping the system clock synchronized in relation to reference clock. You can have the ‘ntpd’ daemon on the Pi use the ‘gpsd’ time signal as a reference clock. It’s also possible to have other mesh nodes in the network synchronize against the ‘ntpd’ daemon on the GPS-equipped mesh node. The following steps will show you how.
GPS-equipped Mesh Node
1) Configure the HSMM-Pi node to use a GPS device:
2) Reboot the HSMM-Pi node and verify that it acquires its location using the GPS receiver. Go to the Status page and verify that a globe icon appears to the right of the node name:
HSMM-Pi Node without a GPS Receiver
You might also want to have an HSMM-Pi node that doesn’t have a GPS receiver to synchronize its time to the mesh node equipped with a GPS receiver. This, too, is pretty easy:
1) Configure the HSMM-Pi node to use the GPS-equipped mesh node as an NTP server. Go to the Admin->Network section, and then select the ‘Time’ tab.
2) Specify the IP address of the GPS-equipped mesh node in the NTP server field. I recommend using the IP address (i.e. 10.201.5.3) instead of the hostname (i.e. KK6DCI-3.local.mesh) because the hostname might not be resolvable at the time the Raspberry Pi boots up, and I’ve noticed that the ‘ntpd’ service ignores unresolvable NTP servers.
3) Reboot the Pi as suggested, and that’s it. You can verify that the Pi is getting it’s time from the other node by running the ‘ntpq -p’ command from a shell:
The NTP server on every HSMM-Pi node can function as a server for other devices on the network. This should make it easy to synchronize a large network using just a single GPS-equipped HSMM-Pi node. Pulling the time from a GPS signal would be extremely useful in a scenario where Internet access isn’t available (i.e. natural disaster).
This evening I upgraded my Linksys WRT54GL router to the latest Broadband Hamnet release version 1.0.0. After configuring the SSID and channel to match those used by my HSMM-Pi nodes, it joined the mesh and worked just as it did with HSMM-Mesh 0.4.3. The Broadband Hamnet distribution does not have the secure plugin for OLSRD, so you will not be able to the secure feature present in HSMM-Pi when deployed alongside Broadband Hamnet nodes; the OLSRD secure plugin is a wonderful feature, but is probably not needed in most HSMM mesh deployments.
Please let me know if you find any incompatibilities between HSMM-Pi and Broadband Hamnet, and I’ll do my best to get them resolved quickly.
I designed the HSMM-Pi project with the Raspberry Pi in mind. It’s a cost effective, compact and powerful platform. However, there are no specific ties to the Raspberry Pi in particular. You should be able to install it on any Debian-based system.
I’d love to hear from anyone who has installed the HSMM-Pi project on a Ubuntu/Debian system using a device platform other than the Raspberry Pi. I’m interested in the Beaglebone Black and PC platforms in particular. I’ll probably conduct my own tests soon, but figured I’d throw this out in case someone has done it already.
Please comment on this post with your findings. Thanks!