Introducing CoovaSX

I recently acquired a Nokia N95 8GB smartphone and started using the WiFi features before making my first voice call. I immediately was annoyed with my own captive portal and having to key in my username and password each time I wanted online - not to mention having to navigate a webpage not made for small displays. The picture on the right shows the embedded browser on my Facebook landing page.

The embedded browser would remember my username (until the cache gets cleared), but never my password. There is now an easier way to login your Java-capable smartphone to your captive portal hotspot - using CoovaSX 1.0! Similar to the firefox extension CoovaFX, but for your phone, CoovaSX will log you into your hotspot without going through the captive portal. Configure your username and password once, then use CoovaSX to login before using the Internet - all without using your browser.

To use the application, your phone must support Java MIDlets (MIDP-2.0). CoovaSX works at hotspots with a captive portal supporting the WISPr XML method of authentication. Visit us in the forum with your comments, questions, or suggestions.

CoovaChilli Update

Now in subversion are some updates to CoovaChilli - which include:

• New options dhcpgateway and dhcpgatewayport to specify a DHCP gateway (relay) host IP address and port,
• New option dhcpradius for mapping some DHCP options into RADIUS attributes and visa versa during MAC authentication, as described here,
• New internal state called splash in which clients are given Internet access, but enforcing the port 80 http redirect,
• New option macauthdeny which will result in the black-listing of devices given an Access-Reject during MAC address authentication, and
• Code cleanups, reorganization, and bug fixes.

Binaries will become available through the forum, where you can also report problems or offer suggestions. For more information on changes in Chilli, see the ChangeLog.

Funding

Just like FON, with their recent $9.5 million round of funding (commentary here), Coova too needed to raise some money. Though, not on such a scale. We had to plop down an extra $550 for a 2 year code signing certificate from Thawte …

There is a standard known to some as WISPr XML - which provides a convenient way for non-browser based authentication on captive portal networks. The technique is used by a variety of smart-client and access controller vendors. Chilli, as an access controller, has long had support for WISPr; initially funded by WeRoam in the original ChilliSpot. Support for WISPr continues in CoovaChilli, and here is how to use it. To test and use this method of authentication to login, albeit, from the browser, install the new Coova Firefox Extension. Tested against CoovaAP and Colubris, it should work with any WISPr implementation.

What does it do? First, the extension checks to see if you are online. It does this by trying to access a page on the Internet - a page not in the walled garden. At Hotspots supporting WISPr, the access controller sends back some XML along with the initial browser redirect to the captive portal. Smart-client applications use this information, which includes the hotspot location name, to login to the network. This extension does the same thing, plus it:

Happy new year!

To bring in the new year, there are new features already live in CoovaAAA and some interesting CoovaChilli development in progress. As mentioned on the mailing list, CoovaAAA now has the following features:

• basic session history graphing
• basic access point bandwidth graphing
• downloading of session data
• access point monitoring notifications
• “open access” MAC address authentication
• updated CoovaAAA Desktop application

The bandwidth graphing and monitoring notification features currently require CoovaChilli. The “open access” feature requires MAC address authentication and currently supports CoovaChilli and Colubris access controllers.

Above, you can see the settings for an access point. If you are using a supported access controller, then the type and basic settings (like reversed accounting) have likely been auto-detected. Note that the bandwidth graph and monitoring alerts are only available currently for CoovaChilli.

Open Access, with Accounting

With open access enabled in CoovaAAA and MAC address authentication configured in the access controller, visitors to your HotSpot are automatically authenticated and given Internet access. Give access to anybody, anonymously, by adding the special anonymous realm to your Allowed Realms, as shown below.

The user experience is no different from an open access point, but you benefit from session and usage accounting.

Graphing & Downloading Sessions

CoovaAAA now has graphs! For the simple session summary graph, JFreeChart is being used - an excellent and easy to use open-source charting library. The graph shows the number of sessions and minutes per day, based on the start time of the session.

This is perhaps not always ideal since sessions can last longer than a day and you don’t necessarily want to graph all that time in one day. Above is an example of the graph showing a mixture of access controller types. Of course, if the access controller doesn’t support RADIUS accounting, like many commercial WPA Enterprise routers, you will not see any minutes for those sessions.

In the same window, you can now download the selected sessions in a comma separated value (CSV) data file. This data file contains Session ID, Username, Realm, Status, Start time, Stop time, Duration, Bytes down, Bytes up, Device, Location, and other attributes taken from RADIUS.

Want to see the overall usage in CoovaAAA so far this month?

(Note: A time-zone conversion issue has been noted where the graph is showing, for example, some sessions on December 31, when the graph should start on January 1st. The system time-zone is US Pacific, my profile is set to Central European Time.)

Graphing Access Point Bandwidth

CoovaChilli can be configured to authenticate itself as an Administrative-User (indicated in the RADIUS Service-Type attribute). This provides a convenient way for chilli to retrieve configuration settings from the RADIUS back-end. Using this RADIUS session, chilli sends global accounting of all running sessions back to the RADIUS server. These accounting requests can be, as they are in CoovaAAA, used for monitoring purposes and/or bandwidth graphing.

For the data collection and graphing, JRobin is being used - providing a pure Java RRD (round-robin database) similar to that RRDTool.

CoovaChilli Development

Last year, I mentioned some interesting features for CoovaChilli which are now in development. To summarize, a number of people in the forum have asked about less restrictive “splash page only” features - where visitors have full Internet access, but with an initial splash page when visitors are web browsing. To provide this, chilli will have a new internal state (not surprisingly called splash) whereby visitors who are otherwise authorized are redirected to a splash page - either the chilli uamserver setting or a session specific URL.

There will be two ways to put a session into this state: 1) with a RADIUS ChilliSpot-Config=splash attribute in the Access-Accept (during MAC authentication, for instance), and 2) using the chilli_query command line utility. To ensure the visitor has been to the splash page, chilli will still require a (re-)authentication via RADIUS to resume full authorized access. To some, it may seem over-kill to require a RADIUS authentication for a splash page acknowledgment. However, doing it this way provides a bit of proof of the acknowledgment in the back-end while also giving the opportunity to reconfigure session provisioning parameters.

Per default, when you use MAC authentication with chilli, an Access-Reject means that the visitor failed to authenticate by MAC address, but still may proceed to the captive portal where they can login. There will be a new option, called macauthdeny, to have chilli ignore all traffic from visitors given an Access-Reject during MAC address authentication - thereby black-listing the device.

Other Development

On a completely different topic, I have recently been working with Diameter and came across this JavaDiameter project. The library provides a very nice pure Java (except for the optional JavaSCTP layer which does use a JNI library) Diameter stack. The API is rather perfect for building a RADIUS/Diameter gateway using JRadius!

There is a new version of CoovaAAA deployed! The highlights:

• Ability to create access policies defining time and data limits
• Share with users or entire realms based on a policy
• Generate a limited number of access codes based on a policy
• Support for CoovaChilli/Chillispot data limits based on a policy
• Stopping stale sessions when the NAC reboots
• Updated Facebook and new general use captive portal
• Bug fix concerning WPA-only option

Access Policies

Access policies define how access is to be provisioned. With this release, you can set the amount of access time and/or the data limits granted in a certain time frame. For instance, a policy might be for 2 hours of access, with a data cap of 10G, to be used within 24 hours. Additionally, the policy can be configured as recurring; for instance, a policy for 2 hours per any 24 hour period. Use policies to limit the access of individual users or entire realms you are sharing with. This includes Facebook users when using the Facebook captive portal.

This screenshot shows the look-and-feel of the Facebook embedded version and how users can individually be configured with an access policy. Similarly, in the next tab, Share with realms, you can configure entire realms with an access policy, specifying whether or not the limitation is for the entire realm (as in everybody has to share the same 2 hours) or if it should be per user (where a new Allowed User is added with the access policy).

Access Codes

In this release, you are able to create 10 access codes based on a access policy of your own. The limit is there while the feature is in beta. When you create an access code, you are basically creating your own usernames and passwords linked to your access policy and network (your own access points). Below, showing the standard look-and-feel, you can see the new Access tab in the manager application and some sample access codes.

Notice how access codes are considered under the realm “code” in the system. This is to not conflict with the default realm of users (i.e. the coova.org realm). Ultimately, when logging in to a network you need a username and password (”credentials”). For the access codes, this means the username, in theory, must be prefixed with this code realm according to RADIUS specification. That gets pretty technical. But, the new Facebook and general use captive portal in CoovaAAA makes it easy by providing a separate login dialog for both users and codes, as shown below. When logging in with an access code, the appropriate realm is automatically prepended.

Captive Portals

The Facebook captive portal was updated. Some adjustments were required as Facebook no longer enforces a login before viewing an application.

Which is nice - since now it is easier to put a login box for Coova-enabled user and access code logins for when the visitor is not a Facebook member.

With the same login box features of the Facebook application, there is now also a general use CoovaChilli captive portal login application. Similar to the embedded captive portal of CoovaChilli and CoovaAP, but this hosted version will be expanded and updated more frequently. It can be used with your own RADIUS back-end or take advantage of the features offered through CoovaAAA - including OpenID authentication (enabled as an option).

Learn more about this newest addition to the Coova hotspot development kit. I’m thinking of calling it this as everything Coova can not only be used as a whole, but also as bits and pieces. With more and more bits and pieces coming in the form of software, tools, resources, and services! If you find any problems or have suggestions, let us know in the forum.

There are new releases to announce, first of all. CoovaChilli version 1.0.11 was released with some bug fixes, leading to a new version of CoovaAP, released as 1.0-beta.7d, to include the new Chilli. Last, but not least, CoovaAAA was updated, as was the Coova HotSpot Facebook application, to work with the new Facebook Pages. Now, you can use CoovaAAA along with either CoovaAP or CoovaChilli to authenticate Wi-Fi HoSpot visitors based on your Facebook Page fans!

Facebook Profile HotSpot

As mentioned, once you add the Coova HotSpot application to your profile you can then configure your Coova-enabled Wi-Fi HotSpot to automatically allow you and your friends to reach the entire Internet - while all other visitors are only allowed access to the walled-garden. It’s a great way to share your Wi-Fi with those you know and for those you don’t know to introduce themselves. Introducing yourself first, after all, is the social thing to do, right?

Facebook Page HotSpot

Facebook introduced pages that you can create for your restaurant, hotel, cafe, club, or just about any other business or organization. Instead of having Friends, like your Profile, Pages allow users to self-proclaim themselves as “Fans” - and gives the page owner a convenient way to communicate with their fan-based. The Coova HotSpot application now supports Pages in addition to Profiles as being the “owner” of a HotSpot. Just like how the Profile HotSpot allows only you and your friends Internet access, the Page HotSpot will automatically login the Admins and Fans of the page. Follow the directions for setting up your HotSpot, but use the “Page ID” instead of your “Profile ID” as the HotSpot owner.

How To Setup

The first step is always to add the Coova HotSpot application to your profile. You need this in your profile before you can setup or access a HotSpot using the application. Before setting up a HotSpot, you will also need to sign-up for a Coova account. Link your Facebook profile to your Coova account by clicking on the Coova Hotspot application link on the left navigation bar in Facebook. Login to the embedded CoovaAAA manager once to link the accounts. The next time you visit the manager, you will be automatically logged into Coova.org.

Next, proceed to create your page and also add the Coova HotSpot application to the page. Configure CoovaAP or CoovaChilli as described in the directions using the Page ID as the HotSpot owner, as explained above, and your personal RADIUS shared secret from your Coova account. Oh, don’t forget to publish your Facebook page!

When you have your page and HotSpot setup, connect to your HotSpot logging in to Facebook as an admin of the page. The first time you do this, you will be given instructions on how to link this page to your Coova account, as shown here:

You’ll notice that the example Facebook page used here was created with name “Cafe Wi-Fi” and this Facebook user account is an Admin of the page (note: the “HotSpot Cafe Wi-Fi” title comes from the Location Name configured in the HotSpot / Location section of the CoovaAP admin interface). This Facebook user is already linked to a Coova account. After making sure the HotSpot is configured with that Coova account’s RADIUS shared secret, link the page to your Coova account by clicking on do this now!. Then, with the HotSpot properly configured and linked to a Coova account, Admin users are automatically logged in:

When a Facebook user, who is not a fan, tries to access the Internet, they will see:

Where the links on the page will take the user to the Cafe Wi-Fi Facebook page - where the user can sign-up as a Fan. Once they do, they will be able to get on-line:

It’s that simple! We will, of course, keep adding features… and suggestions are always welcome in the forum.

Yes, development never stops! There are some new releases to report:

CoovaChilli 1.0.9 has been released. This is largely a bug fix release, see the ChangeLog for details. Binaries for more systems will be available soon.

CoovaAP 1.0-beta.7 has also been released, with the following highlights:

• CoovaChilli 1.0.9
• Facebook HotSpot configuration
• Notes on Upgrading from previous version

As promised, this version allows for easy configuration for the Coova HotSpot captive portal application on Facebook.

New releases of CoovaAP and CoovaChilli are available for download.

New in CoovaAP Firmware version 1.0-beta.6:

• Upgraded wl, nas, and nvram packages
• Upgraded WiFiDog with patch (for CoovaAAA compatibility)
• Default interim interval and secondary server options in HotSpot / RADIUS
• Upgraded coova-chilli to 1.0.8
• Fixes for problems reported in beta.5

New in CoovaChilli version 1.0.8

• See the ChangeLog

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!