The San Diego group will be meeting again on Monday, 12/8.  Due to building security, we will be gathering in the lobby at 7pm and moving to a conference room at 7:05.  If you are not in the lobby by 7:05, then send me an email at callsign@arrl.net and we'll have someone let you in.

Qualcomm Bldg Q,

Sorrento Valley

6455 Lusk Blvd.

See you all at 7pm.

Andre, K6AH

Joseph, You can install the firmware and run the initial setup using wifi or ethernet. Once you've completed steps 1-4 of the installation procedure, you have a working mesh node, and you can only connect to the node via ethernet cable. Even though you see "BroadbandHamnet-20-v3" in the list of wifi SSIDs, you cannot connect to any of the nodes from your laptop while using wifi because the nodes are using a different wireless protocol that is only compatible with other nodes.

My theory is that even though you had an ethernet cable hooked up from your PC to the router, you still had wifi enabled on your PC and actually were using wifi instead of ethernet to install the firmware and do the initial setup. Hint: during steps 1 and 2, the SSID of the router would be "Linksys", and you would connect to the router at http://192.168.1.1. During step 3 and 4, the SSID would be "MeshNode" and you would connect to the router at http://localnode:8080. After you complete step 4, the SSID becomes "BroadbandHamnet-20-v3" and you can no longer connect via wifi because the node is using the mesh protocol, so "http://localnode:8080" will return a "not found" error.

Since you have completed steps 1-4, you have a working mesh node. You cannot connect to the node except via Ethernet.

1. Disable your wifi connection

2. Enable your ethernet connection. Configure the TCP/IP properties to use DHCP

3. Connect an ethernet cable from your PC to one of the LAN ports on the node

4. Make sure that you have an IP address in the 10.x.x.x range by opening a command prompt and enter the command IPCONFIG.

5. Open a browser and enter http://localnode:8080

6. The login name is "root". Enter the password that you setup during the installation process.

If you are talking about using a Raspberry Pi micro computer with a USB wifi adapter and making it work with the various Broad Band Hamnet (BBHN) networks may I suggest:

https://github.com/urlgrey/hsmm-pi

As Conrad said, what the developers support on this site is mainly Linksys and Ubiquiti gear.

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.