Tag Archives: bbhn

AREDN Beta 2

AREDN Announces Release of Second Beta, v3.15.1.0b2

On July 3rd the AREDN Project posted a second beta release of its upcoming v3.15.1.0 software.  It can be found through the Experimental Builds link on the Software Downloads page.  While you are encouraged to download it and report any issues, direct support for this release is currently only provided to AREDN Beta Testers.  Due to the potentially unstable nature of beta software, it should not be deployed in production networks.

If you are already on, then you can easily use the OTA (Over the Air) “keep settings” upgrade!  Joe (AE6XE) did his first 5+mile remote-over-RF upgrade and saved an afternoon and a long uphill hike (This was on a Ubiquiti 3Ghz node).  We’ve had some great feedback on the “part 97 only” channels where they have significantly improved link quality results

In addition, these are ‘clean’ image upgrades that minimize memory usage.  Whenever  ‘patch’ files are used on nodes, this is a memory additive process.  In other words, a replaced file still has old file on the node in addition to the new the file.  These BOTH consume precious system memory.   The OTA upgrade, on the other hand, behaves as if you did a TFTP “clean” image load, but also pulls the config file settings across the upgrade!  It’s a VERY COOL timesaver.

For those of you with tunnels, you will need to go into the Admin interface and click on the “Install Tunnel” button.  However, after a quick install and reboot, all tunnel settings are preserved and no re-entry is needed.  By design, we are not including add-on ‘packages’ like vtun in the OTA.

For the AREDN Team,
Andre, K6AH

AREDN Project Announced!

Announcing AREDN™

The Amateur Radio Emergency Data Network

San Diego, CA: Mesh technology has evolved over the years. Most notably, BBHN (formerly HSMM-MESH) developers have expanded their unique mesh approach to environmentally robust, commercially available, Ubiquiti, hardware. This has changed the complexion of mesh implementations from an experimental, hobby-oriented, novelty into a viable alternative network suitable for restoring some level of Inter/intra-net connectivity when “all else fails.”

This weekend, the developers of BBHN software kick-off a new project focused on taking this technology to the next level. Comprised of the project manager, developers, and several of the testers who brought BBHN to Ubiquiti hardware, this team is geared to pick up where BBHN leaves off.

The AREDN (“r-den”) Project mission is to provide the Amateur Radio Community with a quality solution for supporting the needs of high speed data in the Amateur Radio Emergency Communications field.

We invite you to download and adopt the AREDN Release 3.0.2 and give us the opportunity to support your EMCOMM mesh implementation. http://www.aredn.org

See us at the Palm Springs Hamfest this Saturday, 3/14, at 11:30 AM, Forum A, for our kick-off presentation.

Choosing the Right Hardware for BBHN Virtual Tunnels

Storage Space is King

The biggest challenge in installing extra software on nodes, such as tunnel solutions, is the amount of storage space that is available.  These devices usually have very limited storage capacity.  For example, a WRT54G has 4MB of flash memory.  This memory is where the entire operating system (OS), applications, and settings, must reside.  After the OS is loaded, we are left with very little space to store extra software (like tunnel/vpn software).   In fact, there is NOT enough space on a WRT54G to even install one of the required components of the tunnel solution.  On the other hand, a WRT54GS v2 has DOUBLE the amount of flash memory (8MB).  This is enough to install the tunnel solution, however, the BBHN project is stopping support for these Linksys devices in early 2015.  All of the Ubiquiti (UBNT) supported devices have at least 8GB of flash memory as well.

For this article, I will focus on the UBNT supported devices, since they have a longer support lifetime.

LAN and WAN ports

In order to support local LAN devices (ie. phones, PC’s, servers, RaspberryPi’s, etc), the node needs a LAN port.  This port also provides the PoE (power-over-ethernet) that is required to supply power to the node.  The WAN port provides access to the internet (or, perhaps, your local “home” network).   As long as you do not need to access the internet from your node, you really don’t need the WAN port.  However, since we are talking about virtual tunnels over the internet, we obviously need a way to get access to the WAN port.

Lonely Ethernet Ports

One of the “drawbacks” of the UBNT devices is that most only have a single ethernet ports.  Although the NanoStation models have two ports, the second port has not yet been enabled in the BBHN firmware.  There is an open ticket to support the second port.

So, our dilemma is… how can we provide LAN and PoE and WAN all over a single ethernet port?  Well, the answer lies in a feature/specification called 802.11Q VLAN.


The BBHN firmware uses this VLAN feature in order to provide “virtual lan”, or “virtual ports” over a single port on the device.  The way it works is that the firmware “tags” WAN traffic with “VLAN1” and LAN traffic is not tagged at all.  The switch will route the packets to the appropriate ports with the corresponding tags.

Recommended Hardware

Ubiquiti Nanostation M2 (or M5)
Netgear GS105E Smart Switch (see AE5CA’s article on configuring this)
** The “E” is important in the model number. **

A Final Note on Hardware

AE5CA (Clint) has a done a very nice job of comparing the various UBNT devices.  His blog article titled “Your first BBHN node should be a NanoStationM2” is comprehensive.


Quick Start Guide to AREDN

Load the AREDN firmware on the Node

  1. Download the firmware from http://www.aredn.org/content/software
  2. Connect your PC to the device via CAT5 (easiest way)
  3. Go into AirOS and update the firmware
  4. Let it reboot
  5. Disconnect the CAT5, wait 5 secs, reconnect (to get a new IP address)
  6. Open your browser and go to:   http://localnode.local.mesh:8080  (The node is in PRE_MESH SETUP MODE)
  7. Hit setup
  8. Login (root/hsmm)
  9. Enter your callsign as the the nodename (plus some unique identifier like K5DLQ-UBM2-876, as an example)
  10. Enter a new password
  11. Save and reboot
  12. Disconnect the CAT5, wait 5 secs, reconnect (to get a new IP address 10.x.x.x)
  13. Open your browser and go to:   http://localnode.local.mesh:8080 (The node is now in full MESH MODE)

TIPS to Remember

  1. You cannot connect your PC/MAC via WIFI directly to the MESH!  You must use CAT5.
  2. As an alternative, you can configure a separate wifi access point for general wifi, can plug from it’s WAN port, into your configured switch alongside a mesh node.
  3. To configure for LAN and WAN access, configure your 802.11q switch as follows:
    1. VLAN0 (untagged) = LAN
    2. VLAN1 = WAN access   (can connect from your home network to this port to provide internet to the mesh node)
    3. VLAN2 = DTDLINK (device to device bridging.  For bridging a 2GHZ node to a 5GHZ node via CAT5, as an example)

Links to Note

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!