Operational Notes for AREDN™ 3.0.2

Inter-mesh Tunneling

VTUN can be real useful in connecting mesh islands across non-mesh networks, such as the Internet or other private IP networks.

For instructions on setup and configuration, see the article on AREDN.org

Additional things to remember when using tunnels:

• The OLSR protocol runs over the tunnel, so mesh networks on the other end of the tunnel appear to be directly connected to your local mesh.
• Only the Client or Server may be installed on any given node.
• Nodes still running 3.0.0 which are connected via RF to a tunnel server or client may not be able to access the Internet at their local node unless they update to 3.0.2.
• Internet gateway traffic across the tunnel is blocked by design.   It is a decision for the local mesh Administrators to coordinate if it is appropriate or not for their local users to have an advertised internet gateway.   A tunnel, if the only path of connection, may be used to divide nodes on a mesh and isolate who has and does not have Internet access.   To avoid routing failures, if a given mesh has a tunnel and one or more advertised gateway nodes, then the tunnel node must be one of those advertised gateway.
• Tunnels that are Internet-connected will likely not survive major disasters, so use tunnels as a means of building a critical mass to justify deploying services on your network, not as an Emcomm strategy.

Considerations for Band Selection

Addition of the 900 MHz adds a new dimension as it offers several advantages over higher, microwave bands:

900 MHz (M9)

• Penetrates trees and some obstacles
• Usually higher noise levels
• 6dB propagation advantage vs. 2.4 GHz
• Limited available spectrum – limit to 5 MHz bandwidth channels

2.4 GHz (M2)

• Only two non-overlapping 20MHz channels (1, 6)
• Crowded and noisy band, interference from cordless phones, wireless routers and WIFI clients

5.8 GHz (M5)

• Relatively large amounts of spectrum available, easier to co-locate nearby devices
• Typically much quieter than 2.4 GHz
• 6dB propagation penalty vs. 2.4 GHz

For a given gain, the higher the band, the smaller an antenna’s physical size needs to be.  Therefore the propagation penalties of utilizing the higher bands are usually offset by the higher gain of similar sized antennas.

Device Support

This release expands support.  The following Ubiquiti M-Series devices are supported:

Ubiquiti has made a board and code change to some devices manufactured beginning in early 2014 which prevents the loading of our firmware.   We therefore caution that some new devices may not be supported.  We have seen this in the following devices, but may be the case with more:

To confirm whether a device is of this new generation, look at the System tab of the factory installed AirOS. The Firmware Version is displayed at the top left of the System tab. If it begins with XM, then the firmware will install.

Another way to confirm the firmware version is to Tenet or SSH into the device.  The command line prompt will be one of two types as follows:

1. XM: This is the older version onto which the release should load
2. XW: This is the new board/device firmware which doesn’t accept a new firmware load

We have investigated the cause, understand what is needed to support these new devices, and are planning support for them in the near future. 

Bandwidth Selector

We have added a channel bandwidth selector for Ubiquiti devices.  In the Basic Setup screen you can choose between 5/10/20MHz RF bandwidth based on your needs; for 2.4 GHz this affords the possibility of having more non-colliding channels.  Of course, the data rate throughput of the link will track proportionately.

Linksys devices are limited to the 20 MHz channel bandwidth.

Multi-function Reset Button

The Ubiquiti reset button’s function is now based on how long it’s depressed:

• Hold for 5 seconds for a password reset and DHCP server reset
• Hold for 15 seconds and the node will return to “just-flashed” conditioned

SSID Considerations and Compatibility with Earlier Releases

SSIDs are now comprised of two elements:

1. A User modifiable portion: “AREDN”.  Unless you have a compelling reason to modify this, we encourage you to leave it alone, although it might be useful to use “BroadbandHamnet” while transitioning a mesh over to AREDN firmware.
2. A device-generated portion which describes:
   
   1. the RF bandwidth the device has been configured for (ex:“5”, ”10”, or ”20”)
   2. the compatibility version (ex: “v3”)

If you default these values, the full SSID would be: “AREDN-20-v3”.

The SSID compatibility is “v3” so all devices in your network must be of the same generation in order to interoperate.  Currently compatibility extends to BBHN v3 releases, but that cannot be guaranteed to remain true in the future.

Device-to-Device Ethernet Linking

Connecting devices via Ethernet can serve very useful purposes, for example:

• A 5 GHz network backbone cross-banded to 2 GHz last-mile links.  Here M5 nodes are collocated with M2 nodes. 
• Several nodes on the same band are collocated on a hilltop or tower.  The nodes pass traffic between these devices via their Ethernet ports… eliminating congestion on the RF channel.

Where RF paths can achieve a minimum routing cost metric of “1”, Ethernet paths are assigned a cost metric of “0.1”.  As a result you will notice fractional routing metrics in the Mesh Status screen and OLSR routing tables.

Caution must be exercised to avoid routing loops.  For those unfamiliar with this problem, an explanation can be found at:

http://en.wikipedia.org/wiki/Routing_loop_problem

Note that when multiple nodes are attached together, the DHCP service should be turned off of all but one node.  This will eliminate any problems stemming from nodes defining incompatible network addressing schemes on the common LAN.

DMZ and LAN Port Distinctions

If you need the WAN network, you will need an outboard Ethernet Switch that supports 802.1q VLANs (virtual LANs).  Typically this would be a “managed” or “smart” switch. 

Configure the VLANs as follows:

• Untagged = LAN
• vlan1 = WAN
• vlan2 = DTDLINKING (device-to-device linking)

Band-edge Vigilance

These devices utilize the 802.11g standard where transmitted data are contained within 22MHz “channels.” If you choose a different channel, then care must be taken to ensure the entire channel remains within its licensed operating spectrum.  For example, if it’s being operated on 2.4 GHz at 20 MHz bandwidth, in the US under Part 97, then it must be kept to channels 1-6. Higher channels will exceed the upper limits of the ham band.

Additional care must be exercised if International UBNT versions are used.  These devices will not only operate outside the Amateur coordinated broadband segment, but also outside the entire ham allocation.

The 900 MHz band is only 26 MHz of spectrum.  Running 20 MHz of bandwidth would be irresponsible and a gross disservice to hams utilizing the band for other purposes.  Therefore you should set the bandwidth to 5 MHz.  Also, band plans for 900 MHz are coordinated locally, so confirm where in that plan your mesh should reside.

Untested and Unsupported UBNT Devices

The release requires 32MB of memory and 8MB of flash.  Attempting to load this release into anything smaller will result in an error.  This generally precludes older, pre-“M” models from being supported. 

There are two classes of Ubiquiti devices that are not supported.  They will be identified by a highlighted banner across the top of the user interface:

• Untested: These devices may operate with little or no issues.  However, because we have not had the opportunity to test and confirm they work with this release we will not provide technical support for them until we have done so.  You will see a banner across the GUI indicating this status.  Please do not ask for help with these unless you are prepared to assist in testing the new device.  We will fit these devices into a subsequent release as time permits.
• Unsupported: These are devices for which the software is not intended.  They may load the software and they may appear to work to some degree, but we are not prepared to add them unless and until we have a strategy for code development and support for them.  You will see a banner across the GUI indicating the device is not supported. 

Support Approach

We have all been amazed at what these devices can do and are sure you will be excited to build the mesh out with them.  We encourage you to share your successes, so please post your experiences to the forum. 

As a general rule, we will provide priority support to those designing and implementing a “production” network---those in the process of building to a committed EMCOMM client.  For those experimenting with this technology or building out test-beds in a lab environment, we may ask for your patience.  We acknowledge the anticipation around our releases and only hope we can provide a sufficient level of support for those who need us most.

Having said that, we do have an experienced group of developers who have helped us get this release out:

• Andre, K6AH
• Conrad, KG6JEI
• Darryl, K5DLQ
• Gordon, W2TTT
• Joe, AE6XE
• Randy, WU2S

We will assist you in getting your questions answered and issues resolved.  As you gain experience with these new devices, we encourage you to join in and support the newer adopters.

73,

The AREDN Team