Building out a BBHN Mesh Network using Virtual Tunnels

Trees! We love them… and hate them.


Montgomery County, TX, is a heavily wooded part of the great state of Texas.  As we all know, trees are the bane of 2.4Ghz band.  In order to have a practical and effective mesh network, it requires either a high density of mesh nodes, and/or, mesh node(s) that have excellent line of sight (ie. > 40′).  While we are working on solutions to get mesh nodes at higher elevations, in the interim, it would be really nice to be able to build out the mesh and get practical experience in deploying/operating on the mesh.  In order to accommodate this, I propose the use of internet links to bridge the gaps where RF links don’t currently exist.  The technology behind this is called virtual private networks (VPN’s), or, as they are commonly called in mesh-land, virtual tunnels.


VPN’s essentially allow us to extend a network ACROSS the internet to other networks.  Using VPN’s, we can have mesh nodes that are connected across the county, across the state, or across the globe.  Odds are, your company has capabilities such as this for this for remote workers to access things on the corporate network in a secure fashion.  Mesh VPN’s are the same concept.

But it isn’t RF!

Yes, you are correct in that VPN’s are not using RF.  We are HAM’s, we MUST use RF!  I agree to a point, however,  VPN’s do offer several advantages:

  • It gets HAMs excited about the mesh technology
  • It provides for the opportunity to learn how to setup and deploy mesh nodes
  • It provides for the opportunity to USE the mesh and come up with creative uses in EMCOMM (and beyond)
  • It provides the ability to actually demonstrate the capabilities of ARES and the mesh to served agencies
  • It provides the opportunity to “piggyback” actual RF things on the fringe of the mesh (ie. packet gateways, Dstar hotspots, etc.)

While this is CLEARLY a stop-gap solution, I think the benefits of it are valid.



The enabling technology behind the mesh network is the TCP/IP protocol stack.  TCP/IP is used everywhere in today’s work in things such as: cell phones, home networks, remote controlled light bulbs, fancy remote controlled HF rig, and even DStar.  The original designers of TCP/IP did a fantastic job in creating a set of robust and flexible protocols.


So, how I do *DO* this?

I will be creating a series of blog posts to describe the process of creating virtual tunnel links between nodes.  I have created some scripts to make the process easier.  I also plan to undertake some UI work of the BBHN firmware to add some administration pages to the web interface to allow for easy administration of these virtual tunnel links.


Stay tuned!





BroadbandHamNet 3.0.0b02 BETA available!

I have been testing on 3.0.0b02 since it was released (as well as the 3.0.0 experimental), and it is very stable.

HIGHLY recommend updating to 3.0.0b02 ASAP!


From the BBHN dev team…

The bug in release BBHN 1.1.2 announced in August causes OLSR Secure to crash. It is more widespread than originally thought… and it occurs in both Ubiiquiti and Linksys devices.

We have confirmed multiple causes within the Secure module itself, so we have posted a BBHN experimental version 3.0.0b02 with the Secure module removed. We have also added a “watchdog” that looks for an OLSR hung-state and automatically restarts OLSR when it finds it so.

We encourage you to move to this interim release as we continue our troubleshooting. You will find it under “Experimental Builds” on the Software Download page.

Note that we have begun using a new version numbering method which defines the Mesh protocol compatibility in the first digit. Since the Secure module has been removed, you can see that this 3.0.0 release will not be compatible with earlier “-v2″ firmware.

We are sorry for the inconvenience it may represent for deployed networks.
The Ubiquiti Development Team