That is correct, this is the BBHN group (BroadBand-HamNet).

This is the group that started as HSSM with Linksys WRT54's and renamed to BBHN later and added Ubiquiti AirMax devices and as noted at this time we do NOT make a build for the Pi though other groups may.

So where can I find this BBHN group.. a google search of the term brought me right back to Broadband Hamnet site that I am on

thanks  now all I have to do is find BBHN

J

We do not currently produce a firmware for Raspberry Pi's.

Any firmware that does exist for a Pi isn't maintained by the BBHN group.

If any version does exist it would really be up to that group to keep in sync with the protocols and hopefully they have adopted setup instructions to be sure you stay in sync with the current protocol version which is V3 which is the current version recommended by us, however your local mesh network may choose to use a different protocol version.

Do you know what version of the software you installed on the node ? (Hint: it's in the name of the flash file if you still have it and do not recall)

I have several Raspberry Pi units that I want to use for HAMNET.  The problem is there appears to be at least two versions of software in circulation.  I would like to be able to communicate with all of the different versions and hardware/software flavors in common use.   What software should I be using for maximum flexibility.. and PLEASE give a site where I can acquire the software least I pull out what little hair I have left.

Any other suggestions or help would be greatly appreciated

Jim

Joseph,

You have successfully flashed and setup the two routers and they are now part of the mesh network.

1.  Please explain what you are seeing when you plug your laptop into the second node.  Are you seeing the first node?  the second node?  the mesh network?  the SSID? 

2.  Can you reconnect to the first node?  When you click on the "Mesh Status" button on the first node's status screen, is the second node listed?

3.  What is the IP address of your laptop and the IP address of the gateway when you are connected to the first node?  What is the IP address of your laptop and the IP address of the gateway when you are connected to the second node?

Since we are on the topic of flashing BBHN firmware into a Ubiquiti M2, just a quick question: Is it safe to power up the Ubiquiti M2 without an antenna attached? Or would it be wiser to add an antenna before powering up the equipment?

Yes, that is the most common way to do it. Of course, we need to consider the implications of using self-issued certificates – just as we do today for SSH – versus certificates issued by some other trusted verifying authority.  All of this will develop over time and I expect that groups of meshers will have different solutions to the same problem. That is a good thing – provided that approach has documented their rules for what constitutes an acceptable credential and the uses for each type. That way we can compare the rules and possibly derive a rule-set that is usable across wider areas and larger meshes.

Setting up and running a certificate infrastructure is another complication. This needs to be designed carefully to both provide the flexibility we need in our environment (many diverse groups with differing requirements including rapid ad hoc responses) and avoid the complexity and assumptions of typical corporate enterprise  implementations.

There should always be a place for issuing and using simple passwords as we are doing now. The simple, cheap solution should always have a place as a valid credential for many uses.

In addition to your suggestions, we might want to use authentication to differentiate among people or devices that have access to:

-        Specific parts of a local mesh network, like a command post versus a tactical team which focuses on a specific area

-        Specific services where some people are allowed to view a camera and others not.

-        Specific sub-services, where all participants can use the phone services but only within specific call groups.

-        Limiting the geographical reach of a mesh network. It makes sense to develop and test with networks across many states, but it would probably be a distraction, at best, to allow a network in Texas that is supporting an emergency operation to be visible in California, New Jersey or Europe. We might want to turn geographical limits on and off at will, and do so quickly as the need arises, and the local authorities decide.

-        Prevention and detection of abuse or misuse.

All the best,

Randy WU2S

On Behalf Of Darryl Quinn
Sent: Wednesday, December 03, 2014 22:40
Subject: Re: QoS and directory services

Interesting ideas.  Are you thinking about using a public/private key pair (ie. the ssh certs that we all use) to drive the authentication that would control "secure features" of the mesh.

Consider the following potential "authenticated features":

- internet gateway routing

- tunnel server connections

- QoS

Withdrawn:

The Pi Banana Router Board is a different device than I am familiar with.

I don't know but would the new banana pi router board be a good project  for Mesh networking

Sounds to be a reasonable suggestion.

I would add the need to integrate into OLSR Metric to (artificially) degrade the link for reporting so that nodes that are outside the "incident" will attempt to route around it to avoid even routing through a QOS net, that may on its own reduce the contention (if auxiliary connections exist) and when an connection doesn't than it will go through the incident net.

Downside to this is that means is that a packet may go through a lossy path reducing its speed and increasing network traffic at the expense of avoiding the network. If it's non incident traffic that probably will be fine I imagine,

I also wonder how to combine multiple distinct group policies on high level nodes that may want to support multiple groups,  do they need to dedicate to a single group, arrange to coordinate that all the rules for all the groups in the area into one policy?   Do we add the option for most nodes to pull the master policy but set individual nodes override the policy? I know in my case I work on a repeater site that supports 3-5 organizations at any given incident (depending upon activations.

Brain Storming idea on the table:

Create a way for an "Incident/Event Organizer" to define the event on a master mesh node:

1) New setup screen to define incident/event, e.g. "RACES County MOU Drill 12345", "County Marathon Comm Support", etc.

2) Define 'cluster' list of nodes that are allowed to join and allowed to be included in the cluster.

3) Define usage of rule set "A" -- predefined QOS levels

4) Activate

Create a setup page for Node owners/admins to accept and join the incident:

1) create setup page to "join" and "disconnect" to the defined incident using QOS rule set "A".

Anyone can define a given incident cluster on their node, but owners of other respective mesh nodes in the cluster control and choose to join or not. Incident owners work to ensure sufficient coverage of nodes will meet the needs of the incident. Pre-defined "package" install and updates for QOS rules to be applied to the nodes.

Example QOS rule sets:

A) Non-incident traffic is entirely blocked/ignored/dropped.

B) Non-incident traffic is contained at 128kb/256kb/1M/etc. bandwidth

C) ???

Joe AE6XE

Probably have to just paste it or put it in a pastebin or other website location as the forum basically only allows image files from what I have seen.

This might be of some use.  I made some quick-n-dirty changes to the "/usr/local/bin/wscan" perl sript  to show through the individual node signal strengths. This is for Ubiquiti only. This will provide the basic information to see a particular nodes' signal strength under the condition that it has made the 802.11 level 'adhoc' connection to the cell.

https://drive.google.com/file/d/0B2bEy75HhwWhRTl3aHpLanEybFk/view?usp=sharing

save off and copy this file in place of /usr/local/bin/wscan on the node (I might need to tar or zip this to get through virus checkers).   Click on "wifi scan" from mesh status page, look for the "adhoc" rows.  

At the moment changing the channel or name would be the only viable way to zero in on a single node.

An early attempt was made to include a per node aiming solution into the Ubiquiti line for the 1.1.0 release but it was pulled in beta as it was causing some unexpected corruption (and using a bit more memory than I liked to see as well)

With all the work going into the 3.0.0 for stability fixes "feature" items took a back seat for a few months and it hasn't had a chance to be circled around again to see if there is a better way to do it.

You could look at the unofficial aimer program in the backend, it may be possible to modify to look for beacons from a specific MAC address instead of just any node etc.

Greetings everyone,

On the commercial side I know I can do this in software. Over a week ago I was up 250ft on a tower tweaking a link from one site to the other. The problem was that I also had other bbhn nodes on the same site.  My only consideration after the fact was  to change the frequency on that specific point to point link.  is there any other guidance or help on tweaking an alignment between sites.

It now seems that with winter here I probably won't get a chance to touch that node until spring time.

Mike