There are (were?) two problems holding back the Bullet devices from working on the mesh.

The first rumor was there was an indian-ness problem in the radio and the code that made the secure module in the mesh fail.   As I remember, technically, the Bullet was correct, and the WRT54G's, X86 and ARM are all doing it "wrong".  I've personally built and run olsrd on x86, Pandaboards, and Gumstix w/o any problems and connected into the hsmm-mesh with security enabled, so I find it hard to believe that three platforms are wrong, but anyway.   It should be reasonable to make our own 'hacked' module that does whatever translation and basically uses a 'backwards' security module to work with the existing hsmm-mesh.    Anyway, I never got to see becuase you run into the bigger problem first.  

The 2nd issue was there was no ad-hoc support in the wifi stack used in revisions of software in the bullet and that kept you from getting a 'layer 2' connection to even start playing.    It's easy enough to build the latest openWRT which should have updated wifi stack to support adhoc, but mangling that to run on the bullet had it's own annoying buglist.  It builds, but doesn't have any of the goodies to setup root correctly and be workable.

On a whim, I looked at the latest 5.5 firmware release notes and it looks like they have fixed the ad-hoc problem.  Basically, it looks like they just picked up the latest linux projects and merged that into the ubnt firmware.  

If all that's broken is the security part, assuming that's even a real problem I might have enough free time to fix the other things that need attention.

 Has anybody looked into this in the last month or so?  I don't want to duplicate work that's being done.

Thanks,

KE5TNO

That was no rumor! There is/was an endian-ness or byte-sex problem in the secure plugin for OLSR. I put my corrections into the OLSR source code after the last HSMM-MESH release of v0.4.2, the OLSR maintainers have my fixes, and they have been in the last few of the official released builds. Unfortunately, said code hasn't been brought into the HSMM-MESH source code tree and we haven't had a subsequent release. Part of the delay in getting this out is that a minor release of the code would break things in that nodes with previous firmware versions would no longer work with nodes containing the fixed version. There's more to maintaining a project like this than just putting out code. A lot of people start belly-aching when things stop working, especially between minor releases.

Technically the code was incorrect for all CPU architectures! It was luck that same-byte-sex architectures could exchange the secure plugin info back and forth. Problems arose when you mixed certain CPU architectures. Since HSMM-MESH.org only produced code for the WRT54G the endian-ness of the secure plugin data was a non-issue. My experimentation with alternate routers discovered the actual issue. Finding the code that was burping (actually the missing code!) was a real trick as well. BTW, the CPUs in your PCs, Pandaboards, and Gumstix cards all share the same byte-sex or endian-ness. That is why they all mesh together if you have the secure plugin enabled. Throw in a mesh node with an Atheros chip set or a MIPS (not MIPS-el) chip set (to name two) and they won't mesh.

The 'secure' plugin is nothing more than a "secret" hankdshake between mesh nodes. If you don't have the secret handshake you simply don't get listed as part of the mesh but it does not stop you from connecting with other nodes directly with telnet, ssh, http or whatever protocol -- you just needed to know the remote node's IP address since your OLSRd doesn't collect the DNS entries for the other nodes. I think the HSMM-MESH project is about the only one using the secure plugin for OLSR. Since it does NOT provide any real security I'm hoping that our illustrious Chief Developer in Charge decides to remove it from the upcoming versions.

Instead of everyone trying to hack the code, it's far simpler to experiment by commenting out the secure plugin from the olsrd.conf file of all nodes involved if you want to mix nodes that have different byte orientations. This is the way I run my mesh at home because I dink and diddle with different types of routers.

As we've stated before, if you are doing something DIFFERENT with your mesh, please change the SSID of your mesh from HSMM-MESH to HSMM-MESH-YOURCALL or something of that ilk. This is the indicator we suggest to show that a given mesh is 'different'.

-Rusty-