zip text file attached

Attachments
 nanostationm5unsupported.zip [0 KB] ::

Many versions of the hardware exist, you may have a revision that is not yet had a board.info file provided.

If you can provide a board.info file we can work on moving your version into the list.

http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-37-ubnt-firmware/topic-759-help-us-gather-info-on-ubnt-devices.html

This is known and at the moment isn't high on the list to be enabled due to lack of good limits notice and a previous issue in 2011 where we know some hardware out there and avaliable may have flaws untill we learn for sure these are not current issues

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

You can try the procedure here AT YOUR OWN RISK

http://wiki.openwrt.org/toh/ubiquiti/nanostationm5#poe.passtrough

Ubiquiti gives very little info about this port, from what they do give it's meant to run a CAMERA not a full 2nd node so keep that in mind.  I've read posts of these ports being fried by users in the field.  Make sure if you do use it your using 24v 1amp supply to be sure current through the port is at a minimal and reduce risk of frying the port.

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!