I am getting a notice about unsupported hardware on my M5.  The software loads ok, and as far as I can tell its working correctly.

Are Nanostation M5's truly not supported, despite the info on this site which seems to say they are?

I just upgraded my Nanostation M5 to BBHN, but the second Ethernet PoE is not enabled.  Does anyone have a trick to turning this on?  If not, how can I get word to the developers about this?

Would you believe me if I said I was just testing your subnetting skills? I Didn't think so....

Your numbers would be correct yes and what I meant to put up, good catch.

got it.

I think you meant:

SERVER.    CLIENT.     NETWORK      BROADCAST

172.31.1.1   172.31.1.2    172.31.1.0    172.31.1.3

172.31.1.5   172.31.1.6  172.31.1.4    172.31.1.7

172.31.1.9   172.31.1.10    172.31.1.8    172.31.1.11

Ultimately I believe version choice had to be decided in each regional area by it's members so I won't go into what you should or should not do in that regard.

I will take a moment to back up Clint's statement that the issues exist in the software, many of these lines have already been traced and confirmed to exist in 1.0.0.

Most of these reports are being found out on Ubiquiti first and foremost because the Ubiquiti beta team is the most active group I've seen for sending reports in (this is not to say that other groups are inactive just that most reports I am seeing are showing up from them). The beta team has hundreds of hours each this year alone testing. Bug wise I've seen mostly Bugs that hit both or are Linksys based (big issue in 1.1.x with the built in switch)

At the moment no real Linksys team exists, the Ubiquiti team has been picking up the ball and pulling the Linksys builds forward and fixing bugs that have existed for years once they are told about them so bugs do exist in 1.0.0 (see code repo)

The biggest item I can see is that networks have gotten bigger now with those running Ubiquti because they can do things now they couldn't before. Several issues were tracking to traffic levels related which means 1.0.0 can have the issue if your net grows.

Known bugs with routing exist in 1.0.0 So if you do stick with it DO NOT plug in the WAN port unless you are OK with everyone accessing the internet or network plugged into the WAN port (even with mesh GW disabled). This is just one of the many issues the Ubiquiti team has fixed since they started looking at the project.

Ultimately though Clint is right the better tested builds are when we put them in an early release phase the more stable the final build will be and we can avoid issues like the Linksys switch and NAT issues in 1.1.x

Keep to 172.31.* (VPN space based on the previous document)

use /30 assignments on all the below IP address for client/server 

aka

SERVER.    CLIENT.     NETWORK      BROADCAST 

172.31.1.1   172.31.1.2    172.31.1.0    172.31.1.4

172.31.1.6   172.31.1.7  172.31.1.5    172.31.1.8

172.31.1.10   172.31.1.11    172.31.1.9    172.31.1.12

So on and so forth untill you use all up in 172.31.0.0-172.31.255.255

this is where you get the 2^14 networks as it's 2^16 wide but each tunnel needs 2^2 IP's  (sorry I said 2^18 before put my math the wrong direction) 

Note: I say keep to 172.31.* as we previously an published that as VPN space and we may some day need the rest of 172 for other reasons. We already use part of it for NAT mode hosts so we don't want to trample on that.

Mark

I can appreciate your hesitation to move one to the 3.0.0 firmware.  But I do have to take exception with a couple items you said.  

• The Ubiquiti hardware is the real deal.  It works and it works well!  I cannot recommend that anyone deploy a BBHN node in an outdoor location using Linksys.  
• I would say that most of the issues  we have seen in beta testing the newer firmware are problems with the Linksys side not the Ubiquiti side.  The Linksys firware is getting difficult to support.
• The OLSR issue is present in both the Linksys and the Ubiquiti firmware.  It is also present in all the earlier versions but did not manifest itself as much.  Why it has popped up now is the the question the development team is chasing.
• It is significantly easier and cheaper to deploy a node using a NanoStationM2 than is is with a Linksys WRT54G.  The performance is significantly better as well.

My recommendation to the person just starting out today is get a pair of NanoStationM2's, and run the 3.0.0b2 firmware.  Of course 3.0.0 should have a released version in the next few weeks.

Clint

Good point.  It's been a few years since my network calculation days... but here goes...

If we want to stay away from the non-routable class A (10.x.x.x) network, then the next logical would be a class B (172.16-31.x.x).  We could still use a netmask of 255.255.255.252 to get the /30.

If my math is correct:

[12bits] - [18bits]              - [2bits hosts]
[ fixed ] - [server assigned] - [fixed (253=client, 254=server)]

This way, everything that is tunneled will be on the 172.16.0.0-172.31.255.255 network space.  This would give us 2^18 networks.

Am I thinking through this properly?

Hi Clint;

Thanks for the detailed reply.  In light of the info above and what I'm reading on the forums, I think I'm going to stick with, and recommend to others, V1.0.0 for the Linksys routers.   Beta testing and bug chasing can be challenging and fun but not when doing mesh demonstrations, or deploying a network.

It seems the "exciting" developments are all on Ubiquiti but they're not quite ready for prime time.  Maybe at some point when it can be demonstrated the BBHN software and Ubiquiti hardware is stable, I would invest in some Ubiquiti products.  For now, a Linksys running 1.0.0 is pretty stable and useful enough with some simple updates for most purposes today.

Mark K5LXP

Albuquerque, NM

If you are going to programs GUI it's likely better to go ahead and go above and beyond the original instructions which made VERY poor use of address space by only assigning 1 tunnel from every /24 and actually take it down to use /30's  that means instead of only having 2^8 networks we could have 2^14 networks which allows much less chances of conflicts.

Here's what I'm working on next....

Thanks Joe.  I have an old WRT54GSv7 which isn't supported for BBHN, so I flashed with dd-wrt.  It has VLAN capabilities and can function as a 4-port switch.  I'm planning on using it to switch everything at the EOC as well as function as my gateway to the internet and wireless access point if it will work.

I like the price of the GS108E.  I may have to spend the money if this doesn't work.  Has anyone tried bridging two nodes (5gHz point-to-point and 2gHz omni) and the internet with dd-wrt?

What hardware will the DD-WRT APs be? Recommend expanding your diagram to include the switches--this is key to configuring how everything works. You'll need a Vlan capable switch for the gateway mesh node.

If it were me, I'd put in a GS108E switch at EOC. This can be configured to plug all devices in with no special configuration on the mesh nodes other than the IP address reservations and service advertisement.

At the Mobile and Field locations, I'd do a GS105E. If you put in a dumb switch at the Mobile or Field locations (save a few $$s on the cost), then you'd need to turn off DHCP for LAN ports on one of the mesh nodes.

I'm planning on designing my network like this and need help configuring my routers.  I plan on using DD-WRT for the Router and Access Point at my house (EOC simulation) and my truck (Mobile Command simulation) to allow for switching and firewall connection to the internet while bridging my 2.4 and 5.8 gHz networks to the wireless router.

I'm not sure what should be a node, gateway, DHCP server, or how to configure the VLAN for the internet.

Any tips would be greatly appreciated as I move forward.

Thank you,

Gino
K6GRP 

Hi San Bernardinoians.  I'm trying to get Rancho Cucamonga on the map.  Just posted K6GRP-1 through 4.  The only other nodes that show up on the map is in the high desert.

Gino
K6GRP 

My tunnel scripts and tunnels are working well finally!

I even added the following into the /usr/local/bin/linkled script loop to indicate when tunnel connections are active:

...
if ifconfig|grep tun > /dev/null 2>&1; then
  echo 1 > /sys/class/leds/ubnt:orange:link2/brightness
else
  echo 0 > /sys/class/leds/ubnt:orange:link2/brightness
fi
...

This turns on the ORANGE led on my BulletM2 when a tunnel interface is active!

Hello All,

Can anyone advise if the Ubiquity airGateway would be compatible with any of the Ubiquity MESH loads.  I am willing to experiment I am just looking for any others who have tried.

Thank you

Paul

WD6EBY

Mark

You have a valid question.  I will tell you that in my opinion, you would be best served with the 3.0.0 beta.  Yes there are still some bugs to be be worked out, but all of the released versions to date have had some bugs. 

My understanding is that as soon as the Development team can get some more feedback to help verify that their are no "major" issues in 3.0.0 that they will release it.  The more people that are willing to use it now and help validate or find new problems, the better.

As has been explained on these forums many times, the protocol has changed from 1.1.2 to 3.0.0.  The numbering change is to better reflect the protocol changes.  3.x.x nodes will only connect with 3.x.x nodes.  This means that your entire mesh needs to be on the same protocol.  Some people will not want to upgrade. 

3.0.0 supports a lot of new features over 1.0.0.  This is especially true with the Ubiquiti devices.  You have M5 and M900 devices now supported.  I believe that the 900 Mhz devices are going to open a lot of opportunities with BBHN.  There is the ability to use different channel widths.  Device to Device linking is a big plus for major hubs with multiple nodes or nodes on different frequencies.  Being able to reset a password with a 5 second reset button press or restore to freshly flashed state with a 15 second reset button press has been a blessing to me as I have tried to get some tunnels working.  The Aimer function is a big help to get antennas pointed in the right direction and peak signal strengths.  There are a lot of really cool things in the 3.0.0 build.

Unfortunately,  while the Linksys nodes running 3.0.0 will connect to a UBNT node running 3.0.0, all of these new features are not available or, in the case of Device to Device linking, need to be manually configured.  There are multiple reasons why but the big one is not enough memory.  An other is OpenWRT which is the underlying software for BBHN has dropped WRT54G support from its latest versions and many of the new features use code from the newer versions of OpenWRT. A third reason is the actual hardware will not support the new features.

I believe the 3.0.0 beta version is the best choice out there at the moment.  I have been running it here in Waco since it came out.  I updated to 3.0.0b2 when it came out. While I have seen a couple of OLSR crashes, the watchdog has restarted the node and our network has stayed up and been very stable.  My home node has been up for over a week with no OLSR issues.  That will probably change now I posted this. 

Clint, AE5CA

Are you  forwarding the port the webserver uses?

73, Graham, ZL3GSL