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.

My last post was geared toward attracting the network administrators of communities, schools, or companies to come and roam with CoovaAAA. It would be awesome, for instance, if CoovaAAA users could selectively share their networks with the FON community, their classmates at school, or colleagues at work. However, not all of these organizations use RADIUS and those who do are often unwilling to change their setup without strong financial incentives or demands from their users. Which got me thinking, many people these days are creating and linking their communities, colleagues, and friends using on-line “Social Utilities” like Facebook. I have been looking into the Facebook platform and started integrating it with CoovaAAA. The result is turning out better than initially expected!

The Social WiFi Utility

Facebook has an interesting platform. I now realize that it being called a “Social Utility” isn’t just marketing hype. With their API, FBML, FBJS, and FQL technologies combined with the overall friends and network architecture, it is relatively straight forward to create an entire “social networking” application around Facebook or integrate their platform with another. Since CoovaAAA is about managing your WiFi network and sharing it with others, it makes sense to leverage the social network building features of Facebook to create a Social WiFi Utility.

This is made possible with a captive portal application built for the Facebook platform combined with the CoovaAAA authentication services.

The Facebook Application

Facebook enforces that all visitors are members as they are redirected to the Facebook Coova HotSpot captive portal application. Facebook is placed in the HotSpot’s walled garden, so all visitors are able to login and see the owner’s profile - leaving a message or giving a “poke”.

Above is what you see when logged into Facebook, but not a friend of the HotSpot owner. Of course, the owner is always logged in automatically, so are friends, as shown below.

The access point owner must have a Coova account (linked to their Facebook profile). Visitors don’t need a Coova account, but also benefit from having one.

With your Coova account linked to your Facebook profile, you are able to see your usage and perhaps manage your own Coova HotSpot - all from the embedded application.

Getting Started

The latest release of CoovaChilli or CoovaAP is what is needed running on your router - be it Linux or Linksys (and some others).  You will find the documentation in the wiki and you are able to get help in the forum or IRC (#coova at freenode.net).

(updated November 5)

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.

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!

With the newest release of CoovaAP, some new features in Chilli are demonstrated in combination with RADIUS to allow OpenID based authentication. If you are not yet familiar with OpenID, it is a distributed authentication protocol whereby you use a URL for your identity. This URL might be your LiveJournal page, from your MyOpenID account, or any page you desire. Once logged in, your federated identity is valid across many websites. Now it can be used for WiFi access too.

Above is the OpenID login form in CoovaAP’s embedded captive portal. Instead of a traditional username and password, the user’s OpenID URL is entered. When the form is submitted, the OpenID is sent to the RADIUS server (as a username). The RADIUS server, knowing that OpenID was turned on in access point (see below), will discover the OpenID authentication server for this URL and update the user’s (session specific) walled garden before redirecting the user to their OpenID server to log in and grant permission (trust) to Coova.org.

To give an example, I signed up with LiveJournal and configured my personal home page with the following HTML:

<html>
<head>
<link rel="openid.server"
  href="http://www.livejournal.com/openid/server.bml">
<link rel="openid.delegate"
  href="http://wlanmac.livejournal.com/">
...

This will allow me to use my own URL while actually using my LiveJournal identity to log in everywhere. Now, when I log in to the captive portal with my homepage URL, I get authenticated at LiveJournal. Here’s a sample of what their confirmation page looks like after logging in, if not already.

Once permission is granted for this “calling” URL, in this case at coova.org, you are redirected back and logged in to the access point.

Using OpenID with Coova

CoovaAP version beta-1.5 or newer is required for this setup. The HotSpot RADIUS settings must also be configured (as per default) to coova.org. If you have a CoovaAAA account, then use those RADIUS settings. Otherwise, the “coova-anonymous” shared secret can be used.

Using the web interface, configure the HotSpot RADIUS settings making sure Allow OpenID Authentication is Enabled, as shown here. On this same screen, you can now also configure the default session time and idle timeout - to be used when not otherwise set by RADIUS. Save and apply your changes.

With OpenID enabled and using the internal captive portal, a link to the OpenID login form is placed in the default login page. The templates for these pages can be customized in HotSpot / Portal of the web admin.

If you are using your CoovaAAA RADIUS settings, then you will see OpenID sessions, along with everything else.

Well, that’s it! Enjoy… and let us know how it goes.

Google has a lot to offer when it comes to location specific and community information. With the latest release of CoovaAP firmware, some of these features are made easily available to assist in the configuring the latitude and longitude of your hotspot using Google Maps, showing local area Google Maps in the embedded captive portal, and promoting of your hotspot in Google Base.

As shown above, within the web configuration console you can configure your hotspot’s exact latitude and longitude with the help of a map and movable marker showing the coordinates. This information can then be used by the local area map in the embedded captive portal to show visitors general area information, shown below.

Visitors may find this useful. Of course, when they click for more information, they still need to login. But, how did they find your hotspot in the first place?

While the feature is still experimental, shown below in the web console of the firmware, you are able to configure a Google Accounts user’s authentication token to list the hotspot (with geo-coordinates) in Google Base, demonstrated here in this example.

While Google is in the walled garden, you can also show your own calendar of events from within the captive portal. First, get the Calendar HTML code you need; explained here. Next, pick the embedded portal page to insert the calendar into. Below, we place the HTML into the Login Page template.

The calendar now appears on the login page. The events of our specific calendar are displayed and linked to more information.

Sure, pretty much all of Google is in the walled garden. But, Google largely does not provide content - only links to other sites and services on the Internet. Is it worth it for you?

What about ads? Check your terms of service before putting AdSense in the captive portal or frame - unless you are able to put all the advertisers in the walled garden.