I've been through this process and sorry to say, someone will need to find more time to document how to do this setup--not everything is captured in the repo. I have attempted to do this by developing a script that will setup a full development environment that compiles everything--to save a lot of time figuring it out on your own. Please separately send me email at ae6xe@cox.net if anyone is interested in this script.

HOWEVER, you still need to familiarize yourself with openwrt.org and buildroot.org site and their framework to have a clue what to do with this environment (not to mention familiarity with doing embedded development, linux, etc.). This is a solo effort pre-requisite over a long period of time you must have incurred or plan to incur. Otherwise, plan on beating your head against a wall in frustration :) .

BBHN firmware is ~95% built on top of openwrt.org, olsrd.org, and buildroot.org . The only actual source code being compiled to create our firmware is some parts of olsrd to fix bugs that olsrd.org has not incorporated yet. But this ~5% is significant--don't think this is minimized--it is the smarts of how to configure a node for our specialized setup. bbhn custom stuff is in perl for the mesh status, setup pages, etc.(the gui) and the linux custom config files.

I applaud the guys with the initial vision to use these building blocks to create bbhn.

Joe AE6XE

Given your tree and hill situation have you considered 900 MHz?

The 3.0.0 Beta will load on Ubiquiti NanoStation LocoM900 and NanoBridge M9.  These devices are in the early phases of testing and are definitely not fully supported at this time.  A warning banner will come up on the web interface indicating that they are not fully supported.

Version 3.0.0 added a feature to set a 5 MHz, 10Mhz or 20MHz channel width to the setup screen.  Since the entire 900 ham band is only 25 MHz, I recommend using a 5 MHz channel width.  The 900 Mhz channels should be in the channel pull down.

The 3.0.0 Beta is on the BBHN website under downloads, Linksys or Ubiquiti, experimental downloads.  For the NSL M900 or the NBM9 use the Bullet Factory .bin file the same as you would for a NanoStaton Loco M2.

A few more people trying out the 900 MHz gear could really help in getting it fully supported.

You can connect a M9 or a M5 to a M2 by using device –to-device linking.  Basically just connect the Lan Ports together or you can use a switch that supports VLANS to also add a WAN port and additional Lan ports to the UBNT nodes. This way M2, M5 and M9 devices can all exist on the same mesh.

I have M2, M5 and M9 devices on my network running 3.0.0 today and they are working well.

Clint, AE5CA

You may consider picking up BBHN->ticket:61 (rebase all scripts to dynamically determine interface names) as it relates to what you will need to edit anyways and would be able to be merged into mainline code making it easier in the future for those who need to change interfaces.

I understand that Cisco and 3com gear supports this... but there is a lot of other network gear floating around that doesn't... vlan 1 and 4095 on some switches are treated special and can not be trunked or tagged...That behavior conforms to the 802.1q standard... and Cisco gear using hybrid mode can mimic this behavior for operating with switches that can not tag vlan 1.

Certain Dell, HP, and certain other vendors can't handle vlan 1 tagging, which is annoying, but there is a lot of that gear out there in production, and a lot of it on the second hand market for very little money.

The bigger problem is plugging this into a production network, where the IT Security is never going to allow these devices connected to existing networks, because they can't assign vlan's for them, and nobody allows the use of vlan 1 for anything because as you said it violates best practice guidelines.

The reason I'm asking is because we're in the process of dropping a production link into the dispatch room at a university hospital and I know the IT security guys there and they'll laugh me out of the room if I suggest we use vlan 1 for anything :)

It's not a problem, I'm pretty sure I figured out how to change it... Once I confirmed that it worked, I'll post instructions.

Hmm weird it says (for Linksys Builds)

When I look...  I don't think we ever had a 2.0.0 beta, but try a browser cache clear just to be sure.

Edit:

Oh I see the 2.4 listed in the name, that's an architecture version (hold over from the fact we are based on Openwrt) not a release version.  It is currently a 3.0.0 firmware version

Where can I download version 3.x beta?  The only versions I see in the Experimental Builds list are version 2.x.

Phil, W4PHS

No easy way at this time (check the source and bloodhound tickets on this one)

All reasonable switches should let you change the managment vlan or change port to trunked (remember managment vlan is not related to port tagging ). Back when I went through CISCO training it was considered best practice to move your managment vlan away from vlan 1 for "security"

VLAN 1 is many switches "LAN" network so if you just tag the port as a trunk port it should work and our node on vlan1 would be on your LAN for the WAN port so it can go through your router. You would need to change the PVID (untagged traffic id) of the port to 10 to pull the Node Lan into it's own network.

If you have not already try version 3.0.0 beta as the 1.1.x release has a known issue with some hardware.  If it works you know it should be fine in the next release and it's related to a known bug.

Often discussed:

Google: "channel 0 site:www.broadband-hamnet.org" (w/on the quotes)

Most recent talk: http://www.broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-1-general/topic-1113-default-channel-1-why-not-use-channel-0-or-channel-1.html

Ok, not sure why anybody would use vlan 1 tagged for WAN traffic...  but is there an easy way to change this?

There are a number of 802.1q switches out there from different vendors that don't support vlan 1 tagging at all, because the switch uses vlan 1 for management.  

Any chance we can get this moved into the management console so it can be changed?  or will we be required to change it manually?

Does anybody have a howto on changing the default vlans?

I'm very familiar with Linux and networking...  but I thought I'd ask here in case anybody had the steps needed to add a larger LAN segment to the hamnet firmware.

Current the largest setting in the menu system is a /28 network called 13-Host... and we need a setup that is able to run at least a /26 network...  We're hosting a number of servers and work stations that users on other mesh nodes need to access directly...  NAT/Port forwarding is NOT an option because some of the protocols we're be using.

Does anybody have a list of files that need to be edited, or a quick howto?  I'm sure given enough time I can dig around and make it work, but I'm hoping to save hours of guess work ;)

And yes, I understanding using such a large subnet will increase the chances of a conflict, but it's for a small production mesh setup and we'll be able to handle any conflicts that might come up.

Thanks for the help.

I've spent several frustrating days trying to get a Foscam FI8910W IP camera working with my MESH network.  I finally enlisted the help of a Hamnet Elmer who is a professional networking consultant; he spent several hours on the project.  We have both concluded that there seems to be some sort of compatibality problem between this camera and the Hamnet firmware.

The problem is that the camera appears to be unable to pull an IP address using DHCP or possibly it gets an IP, but it doesn't do whatever's necessary to make itself visible to the MESH node.  When plugged into my standard LAN, the camera quickly gets an IP via DHCP, and it shows up in the IPCamera list of available cameras.  When connected to the MESH node, it does not show up in the DHCP assignment list or the MESH status.  We've tries many things including updating to the latest Foscam firmware, doing a factory reset, trying to use a static IP address, etc., all without success.

Can someone please recommend an inexpensive IP camera similar to the Foscam that is known to work well with the current release of the Hamnet firmware?  We would like to have remote pan/tilt capability and other features comparable to Foscam while keeping the price point around $65 which is what a Foscam costs on Amazon.  We don't need outdoor weather protection.

Thanks, Phil, W4PHS

Some of us in the Northern Virginia area have pretty much resigned ourselves to the fact that there is just too much Part 15 usage of Channel 1 to be able to stand up a viable Ham Mesh.  So some have been looking at the possibility of moving down the band to the 2397-2407 range, so-called Channels 0, -1, -2.  Apparently there is a way of doing this using DD-WRT, but we were wondering if this idea has been looked at/tested for BBHN mesh?  Our issues about moving up in freq to 3.4 or 5 GHz are related to too many trees, too much terrain and too much distance between stations, so right now moving down in the 2.4 band seems a viable option?  Thoughts?  Comments?

>Where <repo_name> is the name the repository you wish to checkout.

There seems to be 3 possible choices at the moment:

• bbhn_ar71xx
• bbhn_brcm24
• bbhn_packages

However, I can't find a READ.ME or a README.md in any of them. Could you explain what each is for?

Hey, KG5DPV. In Coppell about to order a Rocket M2 and Omni.  Don't know if I'll be within range to mesh with anybody but going to run a second node to have a mini mesh up. I'll port when I have it up and running. 

73 KG5DPV

Thanks!  I'll look into it.  I have a Juniper 2200 and really can't afford to nuke it.