CoovaChilli, the open-source access controller, is getting better all the time. Thanks go out to the growing forum, mailing list, and IRC communities for valuable patches and ideas! There is no wonder, then, why CoovaChilli continues to be used in more networks; municipal, mesh, and individual. I hear that Moovera is using it, and I have been helping out Open-mesh.com in integrating it. If you have more success stories, please do share. We like hearing about that sort of stuff.

Open-mesh.com

With Open-mesh, you are able to select one of several pre-defined service providers using the dashboard. They will also follow up with a more generalized configuration option for using your own RADIUS and captive portal settings. You can now select CoovaAAA, our free hotspot AAA service, to manage your open-mesh hotspots by following these instructions. This will use Coova’s basic login form captive portal. Once the more generic configuration option is available, then you will be able to utilize any Portal / RADIUS combination - including Drupal and Facebook.

Image

For assistance, feel free to join the forum or a mailing list, after rereading the directions.

CoovaEWT

CoovaEWT is our web-based configuration system. It comprises of two main pieces: the web application and the web services that drive it. The web application itself is pure static HTML and Javascript - able to run in any web container (browser, Adobe AIR, WebKit, XULRunner, Firefox add-on, etc).

The web application uses Ajax calls against the EWT web services to build the user interface screens, get and save configurations, and can do wizard like interactive dialogs. A wide range of user interfaces are able to be defined in XML and shell scripts that reside on each device - accessible by  a single web application.

Image

A recent snapshot of the CoovaEWT web application is includes in the just released CoovaFX version 1.3. Right click on the (enabled) Coova icon selecting Launch CoovaEWT under the Config menu. This will bring up the embedded web application, ready for you to enter the IP Address of the CoovaEWT enabled device.

Image

Of course, you will need to have a CoovaEWT enabled device before this application is usable, see below.

Also in the version 1.3 release is the ability to change the User-Agent used in WISPr requests.

Open-mesh w/ EWT

While doing a bit of work on open-mesh routers, I found it nice to have at least a minimal user interface. If for nothing else, to check status information and start and stop chilli.

Image

Download and install capd-open-mesh.

OpenWrt w/ EWT

Very much a work in progress, but enough to play with and get started using. Backup your UCI settings before using. After making changes, be sure to verify your UCI settings.

Image

Road to CoovaAP 2.0

Many people have been asking about a new release for CoovaAP. While there are some bugs, it still remains probably the best, most integrated, open-source Hotspot-centric firmware available. The difficult issue going forward is that the current version is based on OpenWrt WhiteRussian which is no longer supported, even in the slightest, by OpenWrt. Upgrading to Kamikaze is the right thing to do, however, it brings other complications - like the lack of nvram, a completely new configuration system, and a wider range of hardware and software to support. For CoovaAP 2.0, the Kamikaze version, the idea is to use CoovaEWT for the web interface and package everything for easy installation on stock OpenWrt devices, using the standard software repositories.

However, with X-Wrt, Lua, and LuCI being more integrated into the stock OpenWRT distribution, it may become problematic as I foresee configuration and init script differences and conflicts. While X-Wrt tries to make everything (but the kitchen sink) configurable for software application, CoovaAP is kept simple and integrated across applications to configure for firmware features. The X-Wrt project is moving in the direction of being more integrated, driven by the features presented in their web interface. But, with their feature configuration logic tied to their web interface (and dependencies), it is unlikely that we can combine efforts. In my opinion, OpenWrt would be better off abstracting the feature configuration logic into an API (which could be UCI itself) separate from their web presentation. If they did this, I believe it would broaden the development community and better the project by not limiting the feature set to that of one web interface.

In the end, we will probably have to distribute pre-built images for CoovaAP 2.0 set to use our own repositories. With no ‘upgrade path’ between WhiteRussian and Kamikaze, it would be nice to keep supporting the CoovaAP 1.X branch - for this we ask for community involvement and support!