Open Mesh Compatibility

Hi Brian,

Thanks!

And good question! We'll need first the gateway to be compatible with the open-mesh firmware (iptables rules) and maybe add something to the auth-server to be able to support the mesh dashboard, if any available.

I started working on open-mesh, trying to use the coova-chilli already in place to send us authentication credentials. But the version of coova on the firmware wasn't the one that could redirect us the information through http, but I heard latest test firmware of open-mesh does have the right version in, so maybe I could look at that again.

In the meantime, I thought I should try to make wifidog gateway work with the olsr package and see where that leads, no work on it done yet. And it may take a few months before I get the time to really get into it.

Maybe someone else will get to it first!

Geneviève

While I am no coder, more of a script kiddy, I have lots of available hardware and can set up a test network with different firmwares. Basically, whatever I can do within my abilities I offer.

We started out with wifidog years ago, but switched to open mesh for the mesh ability. This feels like coming home. I can not believe how far you guys have come on the new code in such a short time.

Thanks for the offer! We haven't really tested wifidog with any mesh software yet so what you could do is try to install the wifidog package on your different firmwares and see if it works out of the box (probably not though) or find out why it doesn't work. Maybe some iptables rules compatibility issue? or the way the network is configured? But knowing where the problem is will certainly help us find the solution.

I'll give that a whirl this weekend - sounds like fun!

Hi Brian and Geneviève!

I can confirm Geneviève's observation that the development version of ROBIN now has a version of coova compatible with authpuppy.

Although G. is looking into options for running wifidog directly, I am curious if the problem with curl being unavailable could be circumvented by (re)compiling openwrt, with curl support, directly on an ARM-based platform (e.g. a single board computer with adequate RAM and large filesystem) and not go to the trouble of cross-compiling.

I agree this isn't an elegant solution, but it may require less effort than tweaking the cross-compiler toolchain or modding wifidog.

Finally, along similar lines, I found this announcement on ROBIN forum about a proposed "app store" for the testing version of their firmware.
http://robin.forumup.it/viewtopic.php?t=3084&mforum=robin

"The Robin Application Store feature (along with UCI files and update-UCI files scripts) will provide a framework for outside developers, payment system operators, WISPs, hardware manufacturers and dashboard operators to create new features to extend functionalities and easily add them to Robin. "

The details on APS, however, are so far lacking, and the original announcement is already months old.

westbywest - good to see you

When you mention ARM based SBCs, which I do not have a problem with, I have hundreds of mr3201a and EOC-1650s already deployed. While the ARMs are great going forward, I would hate to throw out the baby with the bath water so to speak.

One of the problems I have had with the robin firmware is they seem to always be going in 100 directions at once, which brings stability and performance problems. From what Mike at open-mesh.com has told me, the firmware-ng they are working on is to improve performance and stability, although I feel it may not be as open a platform.

I sometimes wonder if robin could use the structure that this launchpad seems to provide.

Hi Brian,

My thoughts about compiling under an ARM processor was that it could provide a possible shortcut to getting an instance of OpenWRT with functioning curl support. I.e. compile the firmware stack under a target processor similar to the core on OM1Ps, EOC-1650, etc instead of cross-compiling on a conventional Linux desktop. This suggestion comes from my inference that the current OpenWRT cross-compiling toolchain does not allow for compiling in curl support for ARM. The cost of an SBC with a compatible ARM core and socket for a large SD filesytem shouldn't be that high.

Also, considering that I've also scattered a couple truckloads of EOC-1650s across a few square miles, I'm just as hesitant to render them moot.

That said, I should first spend time replicating the environment where Geneviève encountered her problem before committing to exotic compile environments. I've been able to cross-compile for ARM platform in unrelated dev projects w/o problem, so I may be able to help out.

Ah - so just use the platform to compile the firmware? I would be willing to donate one of these boards to whomever would like to give it a try.

Just to let you know what I did so far.

I followed the instructions there http://dev.open-mesh.com/wiki/how-build-fw-from-source. I think I built once to fetch all the files and then made my modifications.

With the openmesh source file, I changed the coova-chilli package for the version 1.2.3 downloaded probably from the coova web site. I manually put the coova-chilli-1.2.3.tag.gz in the trunk/openwrt/dl directory.

I added this section to the file package trunk/openwrt/package/coova-chilli/Makefile and changed the PKG_VERSION

define Build/Configure
        $(call Build/Configure/Default, \
                --enable-chilliproxy \
                --with-curl \
        )
endef

That is to compile with the http proxy, with curl. The coova team says they plan to have a version without curl, but it is not implemented so far.

When trying to compile, here is the error message I got, when the system runs the ./configure command for coova:

...
checking for curl_global_init in -lcurl... no
configure: error: in `/home/dev/openmesh/trunk/openwrt/build_dir/mips/coova-chilli-1.2.3':
configure: error: --with-curl was given, but test for curl failed
See `config.log' for more details.

And I found no support for curl in the cross compiler toolchain, so abandoned this option.

Having an image for the routers with the chilli-proxy enabled, that would be great! We could go back to investigate that first option to use what is already in openmesh.

Maybe of some help?

dashboard-options-HOWTO

http://trac6.assembla.com/RobinMesh/browser/documents/dashboard-options-HOWTO?rev=524

hi all
support for wifidog has been added (as experimental) in changeset 733

Thanks Antonio! That's great news!