Hello Everyone,

With yesterday's release of the v1.1.0 firmware OLSRd Secure Support is back in the mix.

This is one of the topics on my things to investigate list and I am looking for guidance on how to get started.  My kickoff questions include:

  How do I generate an OSLRd secure key?

  How do I configure my node once I have my OSLRd secure key?

      Where exactly (file path?) should the key be placed on the node?

      What other settings or configuration needs to be completed?

If this isn't the right place to post this topic, please let me know where it should be moved.

Bob, KO2F

Thank you Andre,

I was surprised when I read the release notes and cam across the statement that OLSRd was ON by default.  I wasn't sure I was interpreting the statement correctly and appreciate your clarifying the point again here.

Can you tell us how the key file is generated?

I have spent a couple hours looking for the answer to this question and haven't found it yet.  This suggests that the answer is probably simple, but..  most answers are after you have them in hand.

Bob, KO2F

Hi Bob,

Sorry for not addressing your last post specifically, by the time I got back to responding to posts I thought maybe I had addressed all of your questions... obviously not.

The key file isn't generated, per se, it's there by default.  It is simply a text file with the 16-character key.   When you load the firmware to node K6AH-001, for example, you are also copying the default key file to that node.  Since all nodes have the key file, all nodes use it.  Since all nodes use it... it's really no different than no nodes having it... K6AH-001 plays on the mesh network with everyone else.

Now, if you were to change the 16 character key on K6AH-001, it would not be able to play on the mesh network because the first node it connected to, say KO2F-001, would look at K6AH-001's key and see that it doesn't match its own key and as a result would not add K6AH-001 to its routing table.  OLSR propagates entries in KO2F-001's routing table to other nodes in the mesh.  If it's not in the routing table, it doesn't get propagated.  Therefore, K6AH-001 will not be able to play on the mesh.

Now the converse will likely be the use case you're interested in:  You have a need to "secure" your mesh from unauthorized nodes.  You establish a secret 16-character key and load (via PUTTY telnet or SSH) the file with that key.  You share the key with other authorized users and they do the same.  You now have an isolated mesh that will only route data with others using the same key.  You should note: this doesn't stop malicious users from attacking individual nodes... it only stops attackers from using the mesh.  When additional users are "qualified" to become nodes on your mesh you share the secret handshake (key) and away they go.

I hope I answered your questions.  Looks like to might be a pretty good FAQ for the masses as well.

Andre, K6AH

Hi Andre,

Thank you.  I really do appreciate all of your responses.

As you speculated, it is the latter path that I am exploring.

And, the key is nothing more than 16 characters in a file.  It doesn't get much easier than that.

Bob, KO2F

Just an additional note / reminder,  if you change the secure key make sure to change the network SSID as well.

Users expect that if they see a BroadBand-Hamnet SSID they will be able to connect to it without changing a key or any other configuration.

Keeping the protocol identifier is also recommended (Aka MyNet-v2) to help you manage your network long term and remind users what the hardware is running and segment your upgrades in some cases.