4. Configure the mesh node - this is required every time the firmware is installed

in a browser go to http://localnode:8080/.

At this point the node is acting as an access point, so you can either be connected by a cable to the LAN port or connected wirelessly to the SSID "MeshNode"... "

I am retired from an engineering career, and do not do well with contradictions. Can anybody bring me up to speed on which SSID is the one and only proper one to use on ham radio mesh net?

Thanks in advance, and 73

KW7B

You are partially correct.  There are several contradictions between the instructions on the website and the latest firmware.  This is not one of them.  I have been told that a scrub of this website is (soon) underway and that it is about to undergo a major update.

When you first flash your node, the nodes is setup in a mode similar to access point.  It is not connected to the mesh yet and must be set up.  When the node is in this state you can connect to the node in two different ways.  This first is  using an Ethernet cable between your computer and a lan port on the node.  The other way you can connect is using a wifi connection to the node.  The node has an SSID of Meshnode when is in the setup mode. 

Once you have entered a node name and password twice, then the node will save changes and reboot.  It then comes up in Mesh mode using the BroadbandHamnet-vX.  The X depending on the version.

The SSID in mesh mode has changed several times.  In the early versions it was HSMM-MESH, then with the Broadband-Hamnet name change and the release of version 1.0.0 it became BroadbandHamnet-v1. Version 1.0.0 was not compatible with the prior versions and all nodes had to be updated.  Some very serious security flaws were discovered in 1.0.0 firmware and I do not recommend its use.

Version 1.1.2 introduced some new security measures among other changes and once again was not compatible with the prior versions so the SSID was changed to be BroadbandHamnet-v2.  It also added support for M5 (5.8GHz) devises.  Unfortunately, this version had some bugs that went back into the OLSR code that have proven very difficult to resolve.  These bugs were not found until after the firmware was release and installed on some bigger networks.  I do not recommend this version or the prior versions.

Version 3.0.0 (currently in beta and available in the download section for your flavor of hardware under experimental versions) backed out a some of the changes from 1.1.2, but there were other changes that remained that made this version incompatible with the prior versions and once again the SSID rolled.  This time to BroadbandHament-XX-v3. The XX is the bandwidth of the channel and can be selected in the setup screen of the UBNT devises.  Linksys nodes can not handle the different channel bandwidths and are limited to 20 MHz.  The UBNT nodes can be set for 5, 10, or 20 MHz.  The narrower channel widths are required to be able to use BBHN on a 900MHz node since the entire band is only 26 MHz wide.  Version 3.0.0 will load on a M9 devise but it is still in testing and not yet counted as fully supported.  The narrower channels may also provide some extra punch to make a connection on the 2.4 and 5.8 bands as well.  With this release, the version numbering was revised to show as the first number the SSID version number.  This is to help indicate to the user base that an SSID changes has been made and the need to update firmware. 

The website has yet to catch up with all the latest information, but it will happen.  The webmaster has a day job and a family and only so much time to keep everything up to date.  

Clint, AE5CA

The SSID is prohibited from being BroadbandHamnet on channel widths other than 20mhz on 2.4 ghz by request of core team. This restriction does not apply to other bands and was for Linksys hardware to ensure that they could link to a network named BroadbandHamnet

If you change it to another name it should accept the channel width.

AE5CA wrote:

" Some very serious security flaws were discovered in 1.0.0 firmware and I do not recommend its use."

What security flaws were in 1.0.0?


Mark K5LXP
Albuquerque, NM

Without getting into the specifics, there were ways to gain access onto the mesh network via 802.11 or WAN without deploying a proper bbhn mesh node to do so. Subsequently there would have been opportunity to attack additional bbhn nodes or attached device.

Should anyone think they've found a vulnerability in the current firmware release, please submit a defect or notify a member of the core team separately. It's not in our communities' best interest to post a public notification of potential vulnerabilities until we have had the opportunity to patch or mitigate.

Two security  exist in 1.0.1 and below

1) An input validation which could allow injecting arbitrary settings into olsrd.conf (must be authenticated to do) BBHN->ticket:34 

2) As Joe mentioned a flaw in the routing where a remote user could access the WAN network even when meshgw was disabled or the LAN network (in case of NAT node) as BBHN->ticket:35

Both is these are reasons to avoid 1.0.1 and below, and based on current status 3.0.0 looks to be the best choice for networks.

And +1 on reporting on the side for security flaws, allows us to get a patch together to resolve the issue before we disclose it publicly to reduce the impact to users as is normal for IT software (reasonable fix period before public disclosure).  This may be a HAM network but it still is wise for us to follow normal security methods to protect from malicious sources.

Anyone who wants to get in over the air can just get their own "real" mesh node a lot more easily than they can hack into our system. 

Or simply passively monitor traffic by any one of a number of easy methods. 

Let's face it, we're not "secure" in any real sense on the RF side.

Of course, we do want to fix any software holes, be they "security" related or not.