You may recall a demo I linked to a few months ago in a past article. It is a Google Web Toolkit (GWT) based application - which means it is completely HTML, JavaScript, and CSS based on the front-end - for managing configurations on a CoovaAP device. Using JSON and RPC style callbacks, the application fetches the router configuration and the user interface screens to edit it. It can then push a new configurations to the same small light-weight CGI application, in this case, written in C. The only real bummer about using GWT is that, although very good, it doesn’t necessarily support all browsers (Konqueror, from what I hear) - and the generated application files, even when compressed, can be a bit large for the smallest of devices (about 400K).

I figured the solution to those problems would be to use Adobe Apollo - now named AIR for Adobe Integrated Runtime. AIR is a framework that allows you to build desktop applications using web technologies. I thought it should be easy enough to use with GWT. And it was! With a few modifications to the GWT code to detect if it is using AIR and to allow configuring of the RPC host, the demo is now available as a desktop application!

Of course, you have to install AIR first. This is required on any desktop running the application. For developers, there is also the AIR SDK which is needed to create an AIR package. AIR only runs on Windows and Mac - hopefully they will eventually support Linux! Setting up the AIR SDK, at least on a Mac, was simple. Just unpack the SDK into any directory and put the bin directory in your path (in your Terminal window, use export PATH=$PATH:/path/to/AIRSDK/bin added to your ~/.profile).

To begin, I started with an example. I then proceeded to setup the icons - very important - It has to look good! I created the suggested 4 (128px, 48px, 32px, and 16px square) to replace the Adobe defaults. Next, created the application.xml file following their example.

 <?xml version="1.0" encoding="UTF-8"?>
 <application appId="com.coova.CoovaAP" version="0.0" 
    xmlns="http://ns.adobe.com/air/application/1.0.M4">
        <name>CoovaAP</name>
        <installFolder>Adobe/AIR/CoovaAP</installFolder>
        <description>CoovaAP Router Administration</description>
        <rootContent systemChrome="standard" transparent="false" 
                      visible="true" width="800" height="600">
                www/com.coova.ewt.Home/AIR.html
        </rootContent>
        <icon>
                <image16x16>icons/i16.png</image16x16>
                <image32x32>icons/i32.png</image32x32>
                <image48x48>icons/i48.png</image48x48>
                <image128x128>icons/i128.png</image128x128>
        </icon>
 </application>

Easy enough. But, now I did have to make some modifications to my GWT application. It was designed to only access the server it was loaded from for RPC calls (required by browsers for security reasons). However, with AIR, you do not have these browser limitations. To enable the application to access and configure any device, I adding a GWT login DialogBox - a pop-up asking for the hostname, port, etc - and the following bit of native code to check if it is running in AIR:

 public static native boolean onAIR() /*-{
     return ($wnd.air != null);
 }-*/;

It does a simple check to see if it has the air object in the JavaScript window. The air object is defined in AIR.html - which is just a copy of my standard Home.html for the application. But, this one includes the AIRAliases.js file contained in the Adobe examples (and added to my GWT application’s public source directory). It, among other things, does the following:

In AIRAliases.js:

 var air; if (!air) air = {};

In AIR.html:

 <script src="AIRAliases.js" />

Based on the result of the native method in the GWT code, the pop-up dialog prompts for a RPC hostname and port, as shown below configured to use the demo router (username and password not used in demo).

Other than the new pop-up dialog and the check for AIR, I had to make no other modifications to my GWT application. After rebuilding my GWT application, with www/com.coova.ewt.Home being the output directory in my case, I built the final CoovaAP.air file using the SDK and the command:

adt -package CoovaAP.air application.xml www icons

This produces a completely self-contained desktop version of the GWT web application to work with any remote device, which now only requires the RPC back-end (the CGI) instead of a complete user interface.

Can’t wait to explore what else AIR offers as a desktop runtime - local file access, for example. So far, it looks really nice!

So nice, in fact, I had to make a desktop version of the CoovaAAA Manager!

There is a new version of CoovaChilli in SVN that is getting close to being released as version 1.0.7. There are several fixes and new features, see the ChangeLog for details. One cool feature added is the JSON interface which allows for easy communication for browser based captive portal applications. Meaning, using JavaScript it is possible to use any HTML page as your captive portal landing page just by adding one line of HTML code:

<script id='chillijs' src='http://coova.org/js/chilli.js'></script>

When the page is used as the chilli login page, the script above attempts to load the ChilliController, javascript contributed by Yannick Deltroo (thanks!), and the default login form template. The ChilliController code and default HTML template are hosted by the chilli daemon directly - customizable on a per location basis. For instance, this simlpe captive portal page (picture below) uses CSS to customize the user interface, as does this simple example:

<style>
<!--
#chilliPage {
  border: 1px solid orange;
  padding: 20px;
  margin-top: 20px;
}
#signUpRow {
  display: none;
}
-->
</style>
...
<script id='chillijs' src='http://coova.org/js/chilli.js'></script>

All the elements of the form can be styled individually, or completely turned off like the sign-up link (element ’signUpRow’) in the above example. The coova default landing page uses some simple CSS to produce:

A simple and interactive captive portal page. The ChilliController loads location information (like the location name, “My HotSpot” above), takes care of logging in (using CHAP challenge/response) and periodically checks for login status and session stats, producing:

A captive portal login/status box like this can be easily embedded into any web page! I’m using my .Mac home page … you get the point.

But, this version of chilli still needs some testing… and to be released soon. If you have a computer running Linux with two network interfaces (doesn’t have to be WiFi, you know), give it a try! Bring your feedback to the forum.

There is a new version of the free CoovaAAA service now running. You are now able to selectively configure your account in general, and then specific devices, for MAC Address Authentication! Of course, this only works with supported access controllers and configurations - so, for only CoovaChilli (or ChilliSpot) and WiFiDog captive portals solutions - possibly others. This feature does not work for WPA Enterprise, and not needed as most clients will likely auto-connect with your configured account information.

How to configure for MAC Authentication

When logged into https://coova.org/, edit your Security Preferences to include Allow MAC Authentication, as shown below:

Only if this user-level option is set will any device owned by the you be allowed to authenticate automatically.

Configuring your device

You may already have some devices associated with your account. Find your device which you added by logging in, using WPA or embedded captive portal configured for coova.org AAA, at least once before.

Click on edit and then select the Allow MAC Authentication option. Setting this option means that your device will auto-authenticate using RADIUS at hotspots configured to perform MAC authentication with CoovaAAA services.

You can’t currently add client devices manually. That is a big limitation, I know, but some thought is required to prevent abuse. True, you can spoof RADIUS, but don’t want to make it easy to harvest arbitrary MAC addresses. It requires some thought and anti-abuse measures. Suggestions, comments, and help requests are welcomed.

Note: Using this feature, of course, does not improve your account security! But, for many, a risk they are willing to take for the convenience.

The WiFiDog project offers an excellent and highly customizable captive portal solution. Used by many free community networks and increasingly for commercial and pre-paid WiFi access providers, it offers an access controller application (in the access point) and a PHP based captive portal web application. Whereas ChilliSpot, also an access controller, does not offer much in the way of captive portal other than a generic perl CGI program. As an access controller, WiFiDog and ChilliSpot do similar functions. However, they differ in fundamental ways. For instance, Chilli relies on RADIUS in the access controller and does DHCP internally where WiFiDog requires it’s accompanying captive portal application - RADIUS is done in PHP by the back-end - and does not control DHCP. WiFiDog uses iptables where Chilli does it’s own packet switching. There are many differences as WiFiDog relies more on the web based back-end and Chilli focuses on RADIUS and features in the access controller.

Bringing some of the lesson learned with Chilli, some patches are now available for testing to: improving RADIUS support, add WISPr XML, and introduce MAC Authentication to the WiFiDog suite.

RADIUS improvements include the use of Called/Calling-Station-Id providing MAC addresses, use of Acct-In/Output-Gigaword for accounting roll-over, Acct-Session-Id added to Access-Request, and support for Session-Timeout.

Added WISPr XML support to assist devices and smart-clients in seamless authentication. The embedded XML provides instructions on how to login to non-browser based applications running on the client device. Usernames presented to WiFiDog will be parsed for a realm - which is then used by WiFiDog as the network name. So, for allowing a realm to roam, a “network” can be created with a RADIUS authenticator, for example.

MAC Authentication is being done using the pcap library (for now) and watching for DHCP replies. It is activated by specifying the MacAuthRealm configuration option in the wifidog.conf specifying the WiFiDog “network” to use for authentication and (currently) requires that the network is configured for RADIUS authentication in WiFiDog.

The changes are provided to (hopefully) raise the standards of WiFiDog with respect to RADIUS and WISPr generally, but are also required for use with CoovaAAA - requiring more standardized RADIUS and access controller feature set. Of course, the patches are provided under the Gnu Public License and your testing and use is encouraged! Bring your questions and comments to the community. Enjoy!