*** Release Notes for BBHN 1.1.0 Ubiquiti and Linksys Devices ***
Please keep the following in mind when operating these devices and reporting issues. Note that some of the features of this release are functionally different from the earlier BBHN releases:
5 GHz Devices
This release adds 5 GHz support to our BBHN firmware. The following devices will run the firmware
Bullet M2 Titanium
Bullet M5 Titanium
NanoStation Loco M2
NanoStation Loco M5**
Not Supported (known)
Rocket M5 Titanium
**During our testing we have noticed that Ubiquiti has made a board and code change in some new devices which prevents the loading of our firmware. We therefore caution that some new devices may not be supported.
We have reason to believe that the following new devices manufactured after 1/1/2014 or so are affected by this:
Not Supported based on Recent Manf Date
NanoStation Loco M5
Currently the only way to confirm whether a device is of this new generation is to Telnet or SSH into the device. The command line prompt will be one of two types as follows:
- XM: This is the older version onto which the release should load
- XW: This is the new board/device firmware which doesn't accept a new firmware load
We are investigating the cause and hope to have a fix in the near future.
Compatibility with Earlier Releases
This release is an upgrade for all existing Linksys and Ubiquiti BBHN devices. New features in this release force an incompatibility with earlier releases. The SSID has been incremented to v2, so all devices in your network must be upgraded to the new release in order to interoperate.
Security Issues in Previous Release
A security issue has been found in previous BBHN releases and you are strongly encouraged to upgrade regardless of whether the other new features are compelling. Any person on the mesh could access the network plugged into the WAN port and the Internet regardless of the Gateway control setting.
Device-to-Device Ethernet Linking
Nodes may now be connected together via their Ethernet ports. Examples of this include:
5 GHz network backbone cross-banded to 2 GHz last-mile – M5 nodes are collocated with M2 or Linksys nodes.
Several M2 nodes are collocated on a hilltop or tower. The nodes pass traffic via their Ethernet ports… eliminating congestion on the RF channel.
Nodes are interconnected via a simple Ethernet cable or switches. Yes, this means you can plug local users and Ubqiuiti (or other Linksys nodes) together at a local Linksys node.
Note the VLAN requirements outlined below, in the section on DMZ and LAN Port Distinctions.
For the advanced user, this is accomplished through an upgraded OLSR protocol. Where RF paths can achieve a minimum routing cost metric of 1, Ethernet paths are assigned a coa 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.
OLSRd Secure Support
We have restored use of the OLSRd Secure module which was an active service in 0.4.3 and removed in the 1.0.0 release.
The module does not encrypt traffic on the network. The correct secure key simply allows a remote node to be added to a local node's routing table. This has the effect of preventing users from participating in a mesh unless they know and set the correct secure key.
Note that the OLSRd Secure key defaults to ON and is configurable only via Telnet or SSH. To minimize the likelihood of unintentional/uninformed modification, the GUI interface does not support its modification. Look for more information on the BBHN forum.
DMZ and LAN Port Distinctions
Since the Ubiquiti line of devices typically only have 1 Ethernet port, the standalone device only supports one wired-LAN connection. If you want additional LAN connections, then you will need to add an outboard Ethernet Switch. Depending on the particular switch, connecting to it may require a cross-over (MDI-X) cable rather than the standard, straight-through cable (MDI). Many later Ethernet switches handle MDI and MDI-X automatically (Auto MDI-X). ‚ If they do not, a crossover cable will be needed for LAN to LAN connections. The Linksys-embedded Ethernet switch supports Auto MDI-X. For those needing more information on this, a good source is http://en.wikipedia.org/wiki/Medium_Dependent_Interface.
If you need the WAN network, then you will require an outboard Ethernet Switch which supports 802.1q VLANs (virtual LANs). Typically this would be a œmanaged switch. ‚ Configure the VLANs as follows:
Note: You will consume 2-ports in this configuration, so if you want to end up with the equivalent of what the Linksys WRT54Gx series device offers, then you will need a 6-port switch.
Look for additional support for this configuration in the BBHN UBNT Support Forum.
Ubiquiti devices will not search for BBHN nodes off-channel. The configured channel is the only one on which the device will operate. We are evaluating the Linksys operational characteristics in this area and will likely attempt to conform them to this behavior.
Linksys devices utilize the 802.11g standard where transmitted data are contained within 22MHz œchannels. However, if neighboring Ubiquiti devices have high-enough quality RF links, they can ramp up to 802.11n. This standard operates within 40MHz channels. In most all cases this will not be an issue, because BBHN networks are typically configured to their default, channel 1. 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.4GHz in the US under Part 9t 97, then it must be kept on either channel 1 or 2. All higher numbered channels could cause the devices to 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.
These devices can be configured to either permit or prohibit known encrypted traffic on the RF link. It is up to you to decide which is appropriate based on how it will be used and the license under which it will be operated. These rules vary by country, frequency, and intended use. You are encouraged to read and understand these rules.
These devices are pre-configured with no restrictions as to the type of data being passed.
Instructions are provided if you wish to prohibit known encrypted traffic on the RF link. ‚ This includes: SSL (443), SSH (22), Node SSH (2222), and Encrypted Email (465, 995, 993).
The forum will not entertain discussions on which of these options is appropriate for a given situation. Ultimately the control operator is responsible for making that determination.
Ubiquiti devices output significantly higher power-levels than their Linksys counterparts. Based on the model and antenna gain, you can easily exceed 47 CFR Part 15 effective radiated power (EIRP)‚ limits.
Power levels for devices with dual-antennas, such as the Rocket M, when configured in diversity mode, split the configured power between both antennas... causing each port to individually be 3db below the configured power.
Power levels have a dependency on the configured antennas. You may notice that you cannot set full max power of the device when using only a single antenna. ‚ You may also notice that you cannot use the minimal power listed in the power drop down window. Some of these devices have internal, off-chip amplifiers which are kept in their linear operating range by limiting‚ the upper/lower‚ input power levels.
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 models from being supported.
There are two classes of UBNT devices that are not supported:
- 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.
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 networkork---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 testers who have helped us get this release out:
- Clint, AE5CA
- Doug, W1DUG
- Gordon, W2TTT
- Karl, W2KBF
- Mark, KD5RXT
- Randy, WU2S
- Richard, W2LCN
They will assist us 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 & Happy Meshing!
The BBHN Core Team