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.

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

Hi guys. Need some assistance/guidance on this...
I have followed K5KTF's instructions to install the vtun server on my 54GS. I am seeing two issues:

1) It appears that the firewall is blocking connections from the WAN to vtun. If I disable the firewall (/etc/init.d/firewall stop), i do see successful connections to vtund.

2) Even though these connections are successful to vtund, it looks like OLSRD is not aware of them. ie. no new routes are established in olsrd status pages and no "remote" nodes are appearing.

I have verified that the "iptables -A FORWARD -i eth0.0 -o tun+ -j ACCEPT" commands are in the /etc/init.d/firewall file as described.
I have added the tun interfaces to the /etc/config/olsrd.conf file (and config.mesh file)
I have double checked the vtundsrv.conf file client entries to contain the proper interface "up" commands and addresses.

Any advice, troubleshooting tips?

Thanks, K5DLQ - Darryl

VA3WPN

There are two known VPN solutions as of today, the GRE solution and the VTUN solution.

Both of them has their pros and cons, but in the end it´s up to you and your environment to choose which one is the most suitable.

Also, there are no issues in combining the two solutions, but it requires a hubsoftware. It´s also possible to combine networks of different HSBB / BBHN firmware-versions using hubsoftware, however there´s a slight handjob to be done on the 0.4.3 nodes in order for this to work. No big deal actually.

Yes, VoIP is being used widely over HSMM / BBHN networks and our (SM) network uses this traversing VPN without any issues.

You can have a look at our (SM) hub at http://44.140.236.17:8080

If you need details on the GRE solution please drop me an email and I´ll send you the documents.

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.

A friend  managed to brick a GL.  I thought "easy", because I had reflashed  one of mine.

Hours later I had repeatedly tried three different tftp programmes under W8.1 without success.

I put UBUNTU 14.04 on a USB stick, booted it, downloaded a REAL (unix/Linux) tftp and loaded  the firmware first try.

Sometimes there's no substitute for real software.

73,  Graham ZL3GSL

The issue is related to upstream (OpenWRT) support for the hardware.

It will require checking out the OpenWRT BuildRoot (latest edition most likely), Research on the NanoStation XW patches @ OpenWRT, and system building.

https://forum.openwrt.org/viewtopic.php?id=49305

https://dev.openwrt.org/ticket/16796

https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg24924.html

are just some of the related posts on the subject and are slightly older (ive seen some re-factor work done on the patch since I last looked at it)

Once we get OpenWRT working fully on the devices we can move to supporting BBHN proper on it.

The NanoStation XW patch is a working start in most cases to begin supporting (and is worth loading on the device to try)

Be prepared to pop open the device and access its board, you will need serial port access from the onboard headers to debug the issues.

Example Status: i have a NanoBeam as noted in first URL, i have wifi working but no ethernet on my last run, so far but have been pulled assigned by other bug and haven't been able to work on it) 

Ive got a Rocket M2 Titanium that partially loads but needs RF and Ethernet work (RM2TI is a form of the XW hardware).

All this comes down to build files.

Yep... and receiver sensitivity of -96dBm!  Clint, AE5CA, swears by them. Need a link... nail up a couple NSM2s!

Hey Jim, I've moved our Temecula/Fallbrook discussion to email.

Andre

Andre, Thank you, It sounds great to be able to link them, I do know a local member who has a place up there and I'm sure he would be ok with placing a node in just the right place. I am anxious to get my nsm2, and just ordered another one, even before receiving the first one, (I'm too impatient?) I will begin to roll up my mesh to 3.0 and will be ready to bring the NSM2 on line right away. I keep on hearing about 13 miles with a pair of these, so we'l see ..hoping for good luck. I will start by pointing it at your location just to see if I can pick anything up by luck..I have a pretty good view of the 15 South pass, Pechanga to the west and Anza to the east..basically and the entire Temecula valley to the south. (aprs igate at my qth for reference)73 Jim

PS, do I have this right?..over 500mw output (28dbm) for the NSM2, then combined with a 11dbi antenna for upwards to 4 watts of ERP ?   Yikes!   Do I have that right?

Hi Jim,

No reason to wait on a production 3.x release... the experimental version is holding up fairly well.  Many of us have multiple node networks running it.  

BTW, I have a pair of nodes on a hilltop near Sleeping Indian in Fallbrook, one of which provides coverage to the Santa Rosa Plateau just west of Temecula.  If you know of any property owners (GTARC members?) up there who wouldn't mind hosting an inconspicuous node... we could bridge the San Diego County effort with Temecula.

I work for Abbott and often come up to the plant on Ynez Rd... we should have lunch some time and discuss.

Andre, K6AH (callsign at arrl dot net)

Hi,

I am about to attempt to get into the Ubiquiti hardware with a recent purchase of a pre-owned NSM2.

Since my entire mesh (7 WRTs) is currently running 1.0.0 code, is it best to upgrade everything to 3.0.0 experimental, including the new Ubiq node?

I was waiting for 3.0.0 to become less of an experiment before proceeding, but want to play with the new unit and I do not see a 1.0.0 for it.

Thanks!!

Jim AG6IF, Temecula CA...Webcams and Asterisk-Pi working great on my current mesh.

I am looking for a mesh node, outside from the six I have operating.

Is there anyone on the east side of "The West Hills" I can set a schedule with, and aim the AP's / Routers?

My Brother-in-Law, KB7ON, Paige, and I are much too far apart for P2P.

I am retired and disabled, so will yield to your time budget.

Thanks in advance

kw7b

I belive you mean 1.20 not 1.1 for a bullet

Here is the official wiki from the vendor on the subject for Ubiqutiti gear.

http://wiki.ubnt.com/Firmware_Recovery

It is also the same as our manual for initial TFTP loading on Ubiquiti

http://ubnt.hsmm-mesh.org/products/BBHN/wiki/HowTo/FlashUbiquiti#TFTP

Also you should not power cycle the device it does that on it's own as part of the flash procedure (though it doesn't harm the device as long as it's already finished flashing when you power cycle, that's adding an unneeded risk of accidentally power cycling while still flashing )

Sub note on flashing via GUI and downgrading is a case of you using the wrong file.

Linksys it only supports TRX files

Ubiquiti it is sysupgrade bin files (these are similar to trx files)

Linksys bin files and Ubiqutit factory are for boot level (TFTP) initial deployments.