Short answer:  The current software does isolated mesh networks now with no code changes.  

If you want two or more separate BBHN based mesh networks, just change the SSID, and the two networks will ignore each other.   i.e. Just change the SSID on nodes in your "isolated" mesh network to be "MESH-B" and leave your "general access" mesh nodes with the default "BroadbandHamnet-v1" and you now have two separate mesh networks that won't see each other at all.

SSID is a parameter on the setup page for the mesh nodes in BBHNv1.

No code changes needed, works on all the current platforms as is, no compatibility problems with existing nodes, no need to come up with BBHNv2 and make everyone update the firmware on all their existing nodes.

Long answer:

The olsrd-secure mechanism is intended for keeping out malicious people trying to infiltrate your network, and, IMHO, imposes an unnecessary level of complexity if you're just trying to define two networks. 

Olsrd-secure probably doesn't do as good a job of isolating the two networks, either, because if the SSID is the same, "wrong key" nodes would still try to connect and then fail to authenticate. If you wanted two isolated networks, you'd want to change the SSID even if you use a separate olsrd-secure key.

Olsrd-secure and different keys only makes sense if you're worried about a malicious person with a standard BBHN mesh node trying to break into your isolated network.  Remember, that anyone who can receive your isolated BBHN network can still monitor all the traffic, even if they don't know anything about BBHN, mesh, OLSR, or OpenWRT.  The data isn't encrypted, even with olsrd-secure, and there are plenty of free network tools that will log everything.

I'm concerned about the idea of adding olsrd-secure back into the system. 

When we had olsrd-secure enabled in the 0.4.3 release of HSMM-MESH, it caused a lot of problems with porting new hardware due to big endian problems.  I'm not sure all those issues are resolved.

If you put olsrd-secure into the Ubiquiti devices, you might break compatibility with WRT-54G and other existing "ports" in ways that aren't necessarily easy to fix.  

Don't forget that there are a lot of "ports" of BBHN, other than just WRT and Ubiquiti.  I know people have ported to Raspberry Pi.  I think some people have even managed to connect from Windows PCs, but the code used is very old.  The olsrd-secure plugin has been a big problem in the past with endian problems between problems.  In particular, some of the endian problems may be resolved in the latest versions of the OLSR/OpenWRT code, but the fixes may not be available for all hardware platforms, or may require you to upgrade all the firmware components to the latest level.

Even if you do get all the firmware updated for all platforms, then everyone has to go and reflash their mesh nodes again.  Some people have problems with the process.  Some nodes are not easy to access to update.  Sometimes, you brick the mesh node when you flash it.

(Note: by "ports," I mean someone has been able to make device X connect to HSMM-Mesh or BBHN networks, not that it's a slick, complete, easy to install distribution like the WRT54G or Ubiquiti packages.)

I wanted to add three points to the discussion:

1. It is still not very clear to me why we want to have more security today than we had in 70-s and 80-s (and that's not just about computers and electronics). If we compare BBHN to ham repeaters in 70-s, what has changed? Back then talking over the radio was popular both with hams and non-hams, and one could (technically, but not legally) just buy an FM radio and get on the ham repeater, have fun and/or cause interference. Not much has changed today with WiFi equipment. Why should we not be good today with what used to work back then in the similar situation?

2. We run the omni antenna at our repeater site, here in Mississauga, ON. This means that there is quite a number of hams who could connect to the tower from their house's roof, if they got interested in the technology. And we do want them to just connect, without getting in touch with someone from the club first. This means that even when using the key for BBHN, that is going to be whatever key comes with the image provided on this website. But this way the same key would be available to the new hams as well as the non-hams who were to google up the name and download the image.

3. I also wanted to mention that I once heard the opinion that because in Emergency situations, the law allows a non-ham to use radio frequency, the ham I was talking to wanted us to provide an easy plug-and-play access for non-hams to the network we build, in Emergency situations. This opinion is on the extreme far side of what you are discussing, but still has the right to be.

Having said all that, I would define my own opinion - we should definitely implement the back-off period after several unsuccessful password attempts to save us from the brute force attacks, and maybe add some more transparency and logging on who has connected where, but otherwise I would say we should not be looking at tightening the access to the network, but rather make sure we tighten access on the applications level. And hey, who said your fellow ham can not be the intruder? Also don't offer Internet to the mesh, cause that would be the #1 goal for the young hackers.

73

Anthony VA3IDL

I think that SSL for the node admin page wouldn't be a bad thing to look into.  a self-signed certificate could work; I've been toying with the idea of an addon to the node interface that would allow a user to generate a certificate right in the GUI.  From there, you could just have your browser accept the certificate, and it should let you know if changes due to someone tampering with it.  As long as this was done before the node goes on the air I would think it would be pretty secure and relatively easy to work with.

Well a couple items come to mind.

First the OpenSSL library is about 1mb in size,  that's a lot of additional space on these nodes which may depending upon where you are at, bring little reward.

Adding SSL may concern some operators so it would certainly have to be operators choice (My nodes are running the block known encryption package which means I wouldn't permit SSL admin to traverse my node)

I've actually been playing with the thought of attack this like packet did,  either using a partial passcode, or even better, using a One Time Password so the same code will never work again.