The first thing I see is 2 nodes with zero LQ. This means we have absolutely no good connection to them.

My first question would be what devices each ip is  and what  version firmware they are and how far away they are.

Secondly, the receivers and  antenna have been reported to be better on the nano than a Linksys by the beta team members,  expect to see nodes you use to not be able to see.  

The one with 89 should have a high enough link to exchange names given enough time (not sure if you just started it)  

I don't see where you show the remote node part showing up in the photo.

If you could provide this feedback it will give us a start.

I have an Ubiquity Nano setup with firmware 1.0.1. I can go to localnode:8080 without issue. When I click on the mesh status, sometimes node names are displayed and sometimes just the IP is displayed. When just the IP is displayed I am not able to see any remote nodes and the neighbors are nodes that I should not be able to connect to directly. The only node I should be directly connected to is showing up as a remote node, when it does show up. If I click on any node I am not able to go to that node.

I have tried rebooting and even reflashed the firmware on the Nano. This did not resolve the issue. I have tried various things on my box including flushing the cache, restarting the browsers, and even rebooting the box.

I have attached a small screen shot showing the name / IP issue.

Any advice on resolving this issue would be greatly appreciated.

Attachments
 QTH Mesh Status 1 sm.png [12 KB] ::
 QTH Mesh Status 3 sm.png [10 KB] ::
 QTH Mesh Status 2 sm.png [5 KB] ::

I have a WRT54G V.3 was up and running just fine.  However it had HSMM-Mesh as its SSID.   I changed that and then noticed that it was not running the same firmware as my new nodes.   So I decided to update.   The router has not recovered.  Its power light is flashing like crazy.  the DMZ light is a steady Flash on and Off every 4 seconds.  

My mac is showing me an IP address of 169.254.250.44 but my browser will not connect.   I tried the only 192 IP address and that does not work.  No matter what I try and can not get a browser to connect to it.  

Anyone have any ideas on how to recover this?????

Thanks in advance

You're right that the BBHN team isn't going to do a port for unsupported hardware.  Lots of people have asked for a port to platform X or Y, and there usually hasn't been anyone with the time to create a new package for that software.  We keep telling people they can roll their own, but not many have done it.

Kudos, by the way, to the folks who did the Ubiquiti work.  Looks like a very well done package.

It's important to realize that it's possible to "roll your own" install on other hardware and make a mesh node that will connect to a BBHN network.  Several people have done this, and it's good to know what's been made to work, and maybe get some links or contacts for info or for help.

For instance, I THINK that an Android device could function as a mesh node, but it's difficult to get an Android device to go into ad hoc mode.   If someone had figured out the magic trick to get an android into ad hoc mode, it would save the next person who tries it a lot of work.

I also THINK some people have connected windows PC's to early versions of HSMM-MESH.  It would be great to figure out how to make a Windows PC connect wirelessly to the mesh.  Getting some info on how it was done would be useful. 

Let's not kid ourselves.  This is a great project, but there's not a lot of hand holding even if you do use the official packages on the supported hardware.   It's important to realize that BBHN isn't as simple as just buying a 2 meter rig, attaching an antenna and becoming an appliance operator.  BBHN isn't for appliance operators unless you have a local guru who can help you do the difficult bits.

Making other hardware work with BBHN is way, way above the appliance operator class.  And way above my pay grade, that's for sure.  Porting the full BBHN package into a clean, easy to install package others can use is way, way above that. 

Tell me about your VMWare install.  What were the guest and host OS's?  Was this VMWare running on an Intel PC?  I haven't used VMWare, but I'm familiar with VirtualBox.

I wonder if you could use VirtualBox or VMWare to run a linux client on a Windows machine and allow you to connect a Windows laptop to a BBHN network.  At first blush, I'd think that you'd need to run a lot of software on the Windows side, but maybe not.  If you just put the Windows interface into ad hoc mode, and made it connect, maybe the OLSR and whatever else you need could run in a VM. 

Way above my pay grade again, particularly in my post-lunch stupor.

Of note:

if you install a port from somewhere else do not expect the BBHN core team to be able to support it.  We have no control over outside productions. If you want a guaranteed to work deployment you need to use an official build. If it didn't come from BBHN all support queries would need to be sent to the port creator as they are the ones whom would need to work on the issue.

All *nix like operating systems (Linux,BSD,Unix and probably even MAC) should work if your willign to put in the time to do it manually. 

I could make this run on practically any Linux type router that allows install access(Especially if it runs OpenWRT)  It the packaging of the port that takes the effort.

In my case I am running on a Pi (custom install -- not packaged), Ubiquiti (3 models across 2 bands and 4 units), Linksys,  3x vm's inside of VMWARE, and thats all i bothered to install it on for now.

Message on the Maryland Google Group.  THought I would pass it along.

What: Broadband Mesh Event.
When:  Saturday May 3rd from Noon to 5pm
Where:  Unallocated Space 514 Shaw Court, Suite 105, Severn MD

This event will provide the attendee a good understanding of the
Broadband Mesh Technology.
We have a few speakers lined up but have space for more.  We are looking
at making this event a primo event to get the word out about this use of
technology.  We'd like to get examples of how this is currently being
used in the region.  Also we'd like to have the attendees be able to
learn the differences between the different types of Mesh available.
Most importantly, we'd like to have examples of the equipment in use on
display.

Please reply to me offlist if you are interested in speaking or doing a
demo.

Thanks!  73's

Charlie Fullerton
KB3ZVN 

I have two new modes due to be delivered today. Thinking about setting one up with VoIP and maybe a website. The other I am thinking about taking to my parents house along Rt. 50 in the area of Skipton Bridges / Cordova Area. That one I am going to try and work it on nothing but Solar Power.  But there is also a thought of going Mobile with it.  

I just dont know.  So many ideas, very limited funds.  LOL

I'm wondering what other hardware users have managed to port to BBHN?

There are "standard," packaged ports for some WRT-54G and some Ubiquiti models. 

With a few byte changes in the header, the standard WRT-54G software may work on a number of non-WRT-54G brand routers by other manufacturers, although the flashing process may be different.

There are also some "non-standard" ports where someone has managed to connect to a BBHN/HSMM-MESH network by configuring their own software.  Many of these "ports" aren't easy to install, and may not have all the tools the full prepackaged packages have, but they have been made to work.

I'm aware that some people have gotten Raspberry Pi's to work in a mesh network.  http://broadband-hamnet.org/hsmm-mesh-forums/view-postlist/forum-2-hardware/topic-817-raspberry-pi-a-hsmm-mesh.html

I've heard that there is an old OLSR port for Windows PC, and it has been connected to the older versions of HSMM-MESH networks.   I don't know whether it works with current versions of Windows or with the current BBHN nodes.

What other hardware/software platforms have been successfully connected to BBHN or HSMM-MESH? 

Let me know what you've heard and provide any links you have.

Short answer:  The current software does isolated mesh networks now with no code changes.  

If you want two or more separate BBHN based mesh networks, just change the SSID, and the two networks will ignore each other.   i.e. Just change the SSID on nodes in your "isolated" mesh network to be "MESH-B" and leave your "general access" mesh nodes with the default "BroadbandHamnet-v1" and you now have two separate mesh networks that won't see each other at all.

SSID is a parameter on the setup page for the mesh nodes in BBHNv1.

No code changes needed, works on all the current platforms as is, no compatibility problems with existing nodes, no need to come up with BBHNv2 and make everyone update the firmware on all their existing nodes.

Long answer:

The olsrd-secure mechanism is intended for keeping out malicious people trying to infiltrate your network, and, IMHO, imposes an unnecessary level of complexity if you're just trying to define two networks. 

Olsrd-secure probably doesn't do as good a job of isolating the two networks, either, because if the SSID is the same, "wrong key" nodes would still try to connect and then fail to authenticate. If you wanted two isolated networks, you'd want to change the SSID even if you use a separate olsrd-secure key.

Olsrd-secure and different keys only makes sense if you're worried about a malicious person with a standard BBHN mesh node trying to break into your isolated network.  Remember, that anyone who can receive your isolated BBHN network can still monitor all the traffic, even if they don't know anything about BBHN, mesh, OLSR, or OpenWRT.  The data isn't encrypted, even with olsrd-secure, and there are plenty of free network tools that will log everything.

I'm concerned about the idea of adding olsrd-secure back into the system. 

When we had olsrd-secure enabled in the 0.4.3 release of HSMM-MESH, it caused a lot of problems with porting new hardware due to big endian problems.  I'm not sure all those issues are resolved.

If you put olsrd-secure into the Ubiquiti devices, you might break compatibility with WRT-54G and other existing "ports" in ways that aren't necessarily easy to fix.  

Don't forget that there are a lot of "ports" of BBHN, other than just WRT and Ubiquiti.  I know people have ported to Raspberry Pi.  I think some people have even managed to connect from Windows PCs, but the code used is very old.  The olsrd-secure plugin has been a big problem in the past with endian problems between problems.  In particular, some of the endian problems may be resolved in the latest versions of the OLSR/OpenWRT code, but the fixes may not be available for all hardware platforms, or may require you to upgrade all the firmware components to the latest level.

Even if you do get all the firmware updated for all platforms, then everyone has to go and reflash their mesh nodes again.  Some people have problems with the process.  Some nodes are not easy to access to update.  Sometimes, you brick the mesh node when you flash it.

(Note: by "ports," I mean someone has been able to make device X connect to HSMM-Mesh or BBHN networks, not that it's a slick, complete, easy to install distribution like the WRT54G or Ubiquiti packages.)

Power consumption varies greatly with the version number of the WRT-54G, with the later models using much less power.

I certainly see this as one of the many reasons an area may want to change the key for the area.

I see the Mesh as the next step in amateur radio as well. It will take time to build up the infrastructure but in time we can build up heck of a network.

It is after all "Broadband-Hamnet" not "setup-only-in-a-disaster-net"  we should use it to what its full potential.  It is why I got involved in the project.

Out here in SOCAL  setting up infrastructure will actually be a requirement, we have LOTS of valleys that we have to fill in, having long running networks is a certain need.  We can not just setup for 4 days and be gone, we need to have it in place if we expect to use it out here.

Personally, I dream big, I look forward to the day when a packet can make it from SOCAL to Maine on RF alone (ya I know, very big dream, but hey got to have a goal right?) Some of the packet networks in the past had some very large networks going over time,  packets found a way across the globe, as hams we should be able to do it again.

First find out what the power draw is of the device while it is being used.

I would suggest sizing the battery such that it can handle the power draw for 5 days, without a charge, and without discharging itself beyond 50% discharged.

I would also suggest sizing the solar array so that it can recharge the discharged battery bank within one days worth of sun.

Use midwinter for figuring out the amount of time that would be in your area.

Install a low voltage drop out device. Your battery is going to be the most expensive part, so protecting it from being over drawn is worth investing into.

Consider one of the charge controllers that can take higher voltage panels and drop it down to what your battery will use.

Lots of 240W panels with 30+ V for sale now with very attractive pricing, under $1 per watt.

Sizing the battery and solar array in this fashion will keep you on the air reliably. Configure for worse case scenario, 5 days of clouds, midwinter, etc.

For 24/7 operations off of solar power, you end up building something that might at first blush look way overbuilt.

I just got my roughed out solar powered wrt.  Working it through the paces to see if it is viable before building and implementing  an enclosure for it.  Consists of a 9ah agm battery (similar to a ups battery in size)  a battery life solar panel 2.5w version and the router.   Has anyone else put there mesh on solar power or any hints to things to avoid?

Attachments
 tmp_IMAG0542-294614660.jpg [976 KB] ::