Mesh, GUI, Chilli, AP
Category: Uncategorized Posted: Friday, August 8th, 2008 at 8:09 am by david
Chilli mesh
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.
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.
CoovaFX w/ EWT
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.
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.
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.
Download and install capd-openwrt.
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!
August 8th, 2008 at 1:05 pm
Hi, I’m one of the LuCI Webinterface developers and just want to share some opinions…
First, X-Wrt is considered pretty dead right now, there werent significant updates on the code base over the last few months, just take a look on the repository. Besides the fact that it isn’t even fully ported to Kamikaze yet, their code is a big messy intermix of HTML and Ash snippets which is nearly impossible to maintain in the long run.
Second, with the LuCI project we’re trying very hard to separate core- and presentation logic from web interface design. So a lot of libraries devloped can be plugged out and reused elsewhere with little efford. As a bonus we tried to keep LuCI stuff out of the core system business, we only rely on standard UCI configuration.
Third, a “UCI validation layer” is planned right now to provide a common framework for interface developers to rely on. Such a layer would enable you to extract informations like available options in config files and sections, inter-option depencies, data types to validate input etc.
Forth, I don’t foresee any significant compatibility issues between the different web interface projects as long as everybody plays the UCI game nicely.
Greetings,
JoW
August 8th, 2008 at 11:26 pm
Thanks for your thoughts. It sounds like LuCI is taking a good approach. I’m surprised to hear X-Wrt is “dead” - I thought it was the driving force behind LuCI, but I guess it is something entirely new. Glad to hear that LuCI is being broken up into components - any additional information you have in that regard would be appreciated. With the validation layer, will that be LuCI or standard UCI? Will it include package/feature management? My suggestion is to use XML (DTD and tools) to structure the UCI definitions and provide some external validation. Even if you don’t use XML directly in the UCI validation, it provides a nice way to maintain, manage, version, and transform the configuration definitions. This way, the UCI “API” can be robustly managed and structured for easy use in all sorts of applications. For LuCI, for instance, a transform could be written to generate the actual UCI validation scripts.