Thanks for the great work on the HSMM-MESH firmware.

I am trying to understand what makes the 0.4.0 and 0.4.1 firmware incompatible with the 0.3.3 and earlier firmware.  The 'firmware change log' indicates "updated to olsr 0.6.0 - firmware upgrade required, configuration not compatible with 0.3.3 or older firmware'

I ask because I have some Ubiquiti Pico-Station 2HPs, and Bullet M2HPs that are flashed with OpenWRT Kamikaze and Backfire images that used to work with the 0.3.3 firmware, and no longer work with the 0.4.1 firmware.  In addition, there are a number of members in my local club that will need to upgrade, if I upgrade the deployed images. (One is up a tower at 1,000 feet).

I have flashed a Bullet M2HP with Backfire 10.3.1 rc-2, and installed the 0.6.0 package for OLSRD, and the plugins.  I modified the OLSR configuration to contain the same parameters as the WRT54GL 0.4.1 configuration.  This communicates fine with the 0.3.3 HSMM-MESH firmware, as well as the 0.5.6 OLSRs on the other Kamikaze and Backfire images. It "sees" the 0.4.1 WRT54GL, but can not communicate with it (per HTTPINFO).

Multiple WRT54GLs flashed with HSMM-MESH 0.4.1 firmware work well with each other.

Can someone share with me the 'secret sauce' that causes the incompatibility between versions?

Quick addition:  If I disable 'LoadPlugin "olsrd_secure.so.0.5" in all versions of the routers, everything works fine.  So the incompatibility appears to be in the support of authenticating the OLSR nodes, between different versions, and different hardwares.  Interesting trivia.  With 'olsrd_secure.so.0.5' enabled, the two WRT54GLs running HSMM-MESH 0.4.1 talk to each other, and a WRT54GL running OpenWRT 8.09.1.  The two PicoStation2HPs can talk to each other, but none of the other routers.  The BulletM2HP won't talk with anyone.

For my purposes, I will just comment out the LoadPlugins.

Also note that Bullets are Atheros-based chipset.  A big problem lies also with the secure plugin for OLSR in that it has some problems with the data that it sends out.  Multi-byte elements of the data (integers, longs, and the like) that is sent out are in the byte-ordering of the CPU and not in the proper "network byte ordering".   Unfortunately, Atheros-based chipsets use a byte ordering that is different from the ordering used by the Broadcom chipset and even though valid data is sent out, routers using a different chipset will see it as invalid.

My port to an Atheros-based AirLink101 router was working just fine once the secure plugin was disabled.

I s'pose I'll start looking at modifying the source code for that plugin.  Even though we might not get these mods into the official release of OLSR we can get the Broadcom-based WRT54G to send out "properly" oriented data...  The Atheros routers use a byte-ordering that's just like the "network byte ordering" so they really won't need to be modified.

-Rusty-

Just ran into this myself. So it looks like the OLSR key exchange code is broken.Should we remove it till it gets fixed and use our own variant? Also odd to me with as many systems as I see out there that we are the first to encounter this.

Actually the key exchange wasn't broken because there was no key exchange. :-)
     [Technically, you never exchange keys, you issue "challenges" that are encrypted
      by both ends of a connection. If you have the proper key you can decrypt each
      other's challenges. Doing that successfully will let you into the PARTY! :-]

The problem was more like the timestamps were not net-byte-ordered before being sent out and verifying the responses from crypto-challenges were not getting done correctly either. I have the secure plugin fixed now. The question is "When do we want to release this and break everything again?" This will probably go into the next major release, say 0.5.0, whenever that occurs. David, AD5OO, and I talked about this during HamCom and this was pretty much the consensus.

Since the byte-ordering on the Atheros and other Big Endian processors actually works (only by virtue that Big Endian has the same byte ordering as the 'net') it are the WRT54G{,L,S}'s that need fixing. Still, having the proper code on both ends is a more proper solution.

I also have a PC version of the secure plugin running on my x86 laptop and meshes just fine with my test mesh.

You're right, I'm a bit worried that this wasn't found/fixed by now. Then again, the secure plugin isn't about security so much as it is about who do we let into the mesh. It's more like a secret handshake because other nodes without the right key, on the same channel, with the HSMM-MESH SSID, can still browse the mesh nodes webpages and 'ssh' into a node if they know the right IP addresses.
So, maybe it's not such a big deal because no one uses the secure plugin??? I dunno.

-Rusty-