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.  

Well let me address the quick part of this first. Upgrading nodes,  I'll admit is currently not the easiest of process and not the most feasible remotely (it is actually doable though via various methods since it comes up in a AP mode still)  You will want to keep an eye on BBHN->ticket:54 for this.  Your not alone on that issue, its been voiced by the beta team as well (whom each has probably done more upgrades than any other group around)  that it is something we need to add. It is also an issue that affects me as one of my nodes is in limited access with a second also planned. The ticket hasn't had much progress due to  several other priority tickets in recent months but it is on the list of things we want to be seen done.  Hopefully it will be possible in the nearer future to get those nodes upgrades without any direct interaction. 

Compatibility, now that is a deep subject.  You are right that it creates its own issues jumping versions, and it is not taken lightly. Networks take time to upgrade and planning to do, The choice to go to V2 was done based on needs seen and as many of those needs that would need to jump a version were put in at the time of the build (compile enough changes to justify the version jump.) Some of those needs might not stick out at first, but as we plan ahead for networks to be bigger we have to be ahead of the curve.

Version 3 was in no way on the roadmap for this soon (read as: I had zero items on my personal roadmap that could justify being the cause of a version jump.)  Without being binding (life changes as we move along)  that probably meant I hope at least another 12+ months before the subject even would arise.  Version 3 is ultimately a patch set, we found issues in the 1.1.x build that we think are going to take a couple months to fix, and it just happens it was in one of the parts that was added as a feature (but wasn't the only protocol changing feature added so we can't just roll back to V1)  It was a difficult choice to come out with V3, but was made based on the general appearance that not many networks had fully adopted V2 yet, and that the issues were so severe we needed to provide a new working version.   The goal was to fix the problem and get a release out without a version jump, that didn't pan out and the decisions tree basically got to where we had to make the decisions to pull a set of code that appeared to be a large part of the issues, and get a  more stable release out.

I can attest that a  large number of man hours were put in by the beta team members to find the root cause of why we are having the issues we are having.  I wish I could say from the dev side that we were already able to solve all the problems based on their feedback but we havent.  They have given us significant amounts of detail on the matter and worked with us to make sure we collected all the information we believe could get us  to fix the issue and it puts us where we just have to dig through and find the  lines of code that cause issue.

So in closing, you have a perfectly valid point, and it is absolutely fair to be commented on, especially from the forward thinking mindset you appear to have on the subject.

I think loss of interoperability is a big blow to the future of mesh networking. I can't imagine that all the nets in the world will continually upgrade to the next version. So for travelers, like many of us, it will be a big issue. I intended to run a node as I drove from Maine to AZ this fall. I won't be in any one place long enough to re-flash my routers every time I change networks. 

I have run a number of repeaters in places like Maine, where access is a sometimes thing. Many of the sites are a hard trip by snow machine or helicopter. Get a ride up when the commercial guy has a problem. Not something that will happen for a software change. We are in the process of building a link which will use a hardened military site as one part of the hop. Not an easy place to access when you are trying to keep a low profile.  

And what happens with VPN attached systems? I assume they would need the same version to work together. I have been considering hosting a VPN server at QuartzFest15 (or perhaps QF16--17?) with a link (via firewall) to the outside world. You could leave your home network running and VPN to it through our server. For those that might not know, QuartzFest is a week long hamfest in the desert just south of Quartzsite AZ in late January. Last year I think some 600+ hams attended.

 Other networks could VPN to us during QFnn and attend virtually. In time I envision one of those "Personna Robots" wandering about QF19, attending the seminars, run by a ham in Idaho..or Brazil...

 Obviously the version changes are considered a necessity. Nobody would go to that much trouble, rewriting the software unless it was necessary. I just wanted to voice some issues that hopefully will hide in your mind as you continue developing software for what I consider to be the next big thing in amateur radio.

Ron, N1AHH.

 PS. We will be running a mesh network at QuartzFest 15 this January. Hopefully with a slew of nodes and many services. It will be a great opportunity for us to learn about dense networking, solar operation and general messing about with networks. Interoperability is already an issue.