Drupal “Hotspot” captive portal module

Introducing the hotspot module for Drupal to integrate this awesome Content Management System (CMS) with your CoovaChilli powered hotspot. In case you haven’t used it, Drupal is a powerful and highly customizable content management system written in PHP. It is used for a wide range of websites, from personal blog to large community-driven sites, and enjoys a very active open-source development and user community. Winner of the CNET 2008 Webware 100 Award and participant in Google’s 2008 Summer of Code, Drupal is sure to be well supported and widely used for years to come.

After installing the Drupal core, you can add all sorts of modules to fulfill your content dreams. With the new hotspot module, you can use your Drupal site for your WiFi Hotspot captive portal. Visitors are redirected to a particular page in your site whereby they are able to login and gain Internet access. As of now, the module does not integrate with the Drupal users database - rather, it simply provides a login for CoovaChilli which, in turn, authenticates users via RADIUS. The plan is to integrate the module deeper into Drupal to not only authenticate the Drupal users, but to also make it possible to configure and monitor your hotspot locations within Drupal itself!

Some other modules you might consider for you Drupal captive portal:

• CCK
• Location
• GMap
• Event

Do you use Drupal and want to use it for your captive portal? Come and help make it better by joining us on Drupal or in the Coova forum.

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 …

CoovaChilli & CoovaAP support

It is great to see CoovaChilli and CoovaAP being used and supported by more companies and projects! FON has been using CoovaChilli, Open-Mesh.com plans to, supported by Worldspot, and Coova officially works with Radiator. In fact, CoovaChilli will work with any RADIUS server and it is used by countless wireless ISPs, of all sizes, around the world. CoovaAP, an OpenWrt-based firmware for commodity WiFi routers, provides an easy to configure platform for CoovaChilli access controlled networks and WiFiDog captive portal community networks alike.

WiFi-CPA, a commercial hotspot service company, also uses CoovaChilli and CoovaAP, though it might not be as obvious. They re-branded and modified CoovaAP (which is not ideal, but ok when done right), took and doctored a diagram from this website (removed; thanks!), yet don’t even mention or link to Coova.org (also remedied). They say imitation is a form of flattery; what about copyright infringement? There is also some confusion around the chillispot.info website. As far as I can tell, this is a copy of the original ChilliSpot.org website (with commercial links added) and is not continuing with any development. It does, however, provide a forum for ChilliSpot die-hards, which is helpful for some.

Here at Coova, development is continuing toward a 2.0 release (for both CoovaChilli and CoovaAP), with the emphasis being on stability, performance, and remote manageability — in addition to new features, including those described here in the blog and perhaps here in the forum; not to mention ideas for mesh integration. As with many open-source projects, community involvement, commercial support, and feature ’sponsorships’ are important and welcomed. Thanks to all those who submitted bug reports, suggestions, or patches in the forum!

JRadius & FreeRADIUS user interface

I have been using FreeRADIUS for some time - usually as the front-end to a JRadius server. FreeRADIUS is both powerful and flexible, but I believe many would agree that what it needs most is a graphical user interface. It could also benefit from pre-cooked configurations for typical deployments. Indeed, the same could be said for JRadius and the configuring of it’s handers. Perhaps CoovaEWT can be of assistance. CoovaEWT is a web-based user interface framework that is in development. The “compiled” Ajax (javascript/html) application is free to use and highly extensible using XML and XSLT. The user interface definition itself, the configuration it edits, and the scripts to generate the final application configuration files (e.g. radiusd.conf) are all customizable server-side files. Below are some screen-shots of what’s in development in JRadius.

Above is a typical screen from the FreeRADIUS administration interface - to configure the interfaces, in this case.

In addition to configuring the FreeRADIUS server itself, the user interface is ideal to manage the database tables that come with the SQL module.

Backed by the JRadius dictionary, which is generated from FreeRADIUS dictionary files, the interface is able to help you complete attribute names, so you don’t make any spelling mistakes. More news to come… stay tuned to the JRadius wiki, forum, and mailing list.

CoovaFX on the road

For fun on a recent trip to London, I took a couple screen-shots of the WISPr-enabled networks CoovaFX picked up in various places. I used CoovaFX to log into my hotel network with a voucher username and password I had to buy (boy, WiFi is expensive in London).

The Dynamic Host Configuration Protocol (DHCP) is a standard way for client devices to acquire an IP address and other configurations (DNS, Gateway, etc) on a network. This is particularly true in public access networks; as such, DHCP is integral to chilli, and always has been. Of course, it could certainly be more flexible. As it is now, you can’t really do much in the way of customizing your DHCP configurations. I have some ideas for CoovaChilli, and some DHCP discovery to share.

DHCP and MAC Authentication

MAC authentication is a common feature to access controllers that perform DHCP. It allows for authentication to take place automatically without the need of a captive portal or a web browser. CoovaChilli (and ChilliSpot) has the option to authenticate MAC addresses. Using this feature, initial DHCP requests made by the client trigger a RADIUS Access-Request. Subsequent DHCP requests from the client are granted with an authentication state based on the RADIUS response being Access-Accept or Access-Reject. That will change with the macauthdeny option, to have Access-Reject mean complete black-listing, but more could be done.

Here are the DHCP options found in a request from a Windows XP laptop (the Parameter Request List being the same in DHCP Discover messages):

Option 53: DHCP Message Type = DHCP Request
Option 61: Client identifier
    Hardware type: Ethernet
    Client MAC address: 00:18:xx:xx:xx:xx (00:18:xx:xx:xx:xx)
Option 12: Host Name = "laptop"
Option 81: FQDN
    Flags: 0x00
    A-RR result: 0
    PTR-RR result: 0
    Client name: laptop.coova.org
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List
    1 = Subnet Mask
    15 = Domain Name
    3 = Router
    6 = Domain Name Server
    44 = NetBIOS over TCP/IP Name Server
    46 = NetBIOS over TCP/IP Node Type
    47 = NetBIOS over TCP/IP Scope
    31 = Perform Router Discover
    33 = Static Route
    249 = Classless static routes
    43 = Vendor-Specific Information
End Option

The following Vendor Specific Attributes (VSA) are proposed additions to CoovaChilli in order to forward this information to the RADIUS server during MAC authentication:

DHCP Option                          RADIUS Attribute
--------------------------------     --------------------------------    
Option 12: Host Name                 ChilliSpot-DHCP-Hostname
Option 55: Parameter Request List    ChilliSpot-DHCP-Parameter-Request-List
Option 60: Vendor class identifier   ChilliSpot-DHCP-Vendor-Class-Id
Option 61: Client identifier         ChilliSpot-DHCP-Client-Id
Option 81: FQDN                      ChilliSpot-DHCP-Client-FQDN

Additionally, the VSA named ChilliSpot-DHCP-Options will be optional in either an Access-Accept or Access-Reject, carrying arbitrary options to append to the DHCP response. All attributes are binary octet strings and carry the DHCP options in raw form.

Attributes in the Access-Request contain the corresponding DHCP option value, whereas the ChilliSpot-DHCP-Options contains a list of options, packed as they are in a DHCP message. Combined with the existing support for the Framed-IP-Address RADIUS attribute for IP assignment, this method provides for a high level of DHCP configuration centralized in your RADIUS server.

DHCP Relay Gateway

As the MAC authentication feature has shown, there is no reason why chilli can’t delegate IP assignment. Then why not have chilli act as a DHCP forwarding agent? This would make it possible to centrally manage your DHCP configurations, using a more configurable server. CoovaChilli will be able to forward DHCP requests to a remote DHCP gateway, noting the IP assignment in the response.

This would open up many possibilities… including, perhaps, captive portal settings provisioned through a DHCP server!

Note: You can already use CoovaChilli with access points, like the Cisco Aironet, configured to forward DHCP to chilli.

WPAD and Proxy Autoconfigure

Windows has a feature (in Internet Options, Connections tab, LAN settings button, Automatically detect settings checkbox) whereby browser proxy configurations can be picked up automatically from a network. The Web Proxy Auto Discovery (WPAD) protocol provides browsers (primarily Windows Internet Explorer, and maybe others) with a proxy configuration file. This Proxy Auto-Config (PAC) file can configure the default proxy and can be scripted, as demonstrated in this example, as a banner ad buster. Not without some risks, the configuration is downloaded either based on a DHCP option or a DNS based web server (using the prefix “wpad.” and the system FQDN).

With Automatically detect settings enabled, you will also see the following requests:

Option 53: DHCP Message Type = DHCP Inform
Option 61: Client identifier
    Hardware type: Ethernet
    Client MAC address: 00:18:xx:xx:xx:xx (00:xx:xx:xx:xx:xx)
Option 12: Host Name = "laptop"
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List
    1 = Subnet Mask
    15 = Domain Name
    3 = Router
    6 = Domain Name Server
    44 = NetBIOS over TCP/IP Name Server
    46 = NetBIOS over TCP/IP Node Type
    47 = NetBIOS over TCP/IP Scope
    31 = Perform Router Discover
    33 = Static Route
    249 = Classless static routes
    43 = Vendor-Specific Information
    252 = Proxy autodiscovery
End Option

Replying to either the DHCP Discover, Request, or Inform messages specifying the Proxy autodiscovery option will inform Windows of the required WPAD URL:

Option 53: DHCP Message Type = DHCP ACK
Option 1: Subnet Mask = 255.0.0.0
Option 3: Router = 10.1.0.1
Option 6: Domain Name Server
    IP Address: 208.67.222.222
    IP Address: 208.67.220.220
Option 51: IP Address Lease Time = 15 minutes
Option 54: Server Identifier = 10.1.0.1
Option 252: Proxy autodiscovery = "http://ap.coova.org/wpad.dat"
End Option

With the option specified, and since DHCP takes priority over any DNS based WPAD source, Internet Explorer happily takes the configuration. Even though my Mac sends the following in a DHCP Discover message:

Option 53: DHCP Message Type = DHCP Discover
Option 55: Parameter Request List
    1 = Subnet Mask
    3 = Router
    6 = Domain Name Server
    15 = Domain Name
    112 = NetInfo Parent Server Address
    113 = NetInfo Parent Server Tag
    78 = Directory Agent Information
    79 = Service Location Agent Scope
    95 = Lightweight Directory Access Protocol
    252 = Proxy autodiscovery
Option 57: Maximum DHCP Message Size = 1500
Option 61: Client identifier (6 bytes)
Option 51: IP Address Lease Time = 90 days
Option 12: Host Name = "iMac"
End Option

The Mac does not use the returned Proxy Autodiscovery option, at least not with Safari.

Still, interesting stuff… and could pose a problem if you are at a hotspot and your Windows laptop auto-configures a proxy server that is not accessible in the walled garden!

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!

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 are at least two meanings of WiFi Roaming. First, there is the physical hand-over of a client device from one access point to another - like perhaps in a mesh network. The other, and the one this article is about, refers to authentication, authorization, and accounting (AAA) roaming. Access controllers, like CoovaChilli, authenticate users and provide session usage accounting using RADIUS. Through the RADIUS server, access is provisioned with or without session time or usage limitations and session statistics are collected.

RADIUS Roaming, or Realm-based Roaming, is a feature of the RADIUS protocol whereby messages are forwarded by proxy to a remote 3rd party for processing based on a Realm. A realm in RADIUS is like the domain name in an e-mail address. It specifies the Home Provider of a user identified by a username and is usually formatted in one of two ways: as a prefix realm (e.g. realm/username), or like an e-mail address with a suffix realm (e.g. username@realm).

RADIUS Roaming

In CoovaAAA, when you allow the realm coova.org access (on the Sharing page of the web interface), you are allowing other Coova users to get access using your network. It is also possible to grant login permission to other realms using remote RADIUS servers. If you have a user community (with a RADIUS server) and want to enable roaming with coova.org, contact us! It’s a great - and free - way to share with the community you already know; you’re own.

If your RADIUS server does not support EAP protocols, or they are just too cumbersome to setup, CoovaAAA can help by terminating the EAP-TTLS tunnel and doing proxy for the “inner” tunneled authentication. This way, you can still get the benefits of WPA Enterprise / 802.1X without having to upgrade or reconfigure your current RADIUS installation.

When using EAP-TTLS based protocols, you essentially establish a SSL connection (over UDP) directly to the RADIUS server. Over this tunnel, “inner” authentication can be performed using the user’s true username and password. The “Supplicant,” or client software (the internal Macos X Internet Connect or SecureW2 for windows, for instance) establishes this connection and verifies the certificate of the RADIUS server it is talking to. If trusted, then authentication is performed.

RADIUS Accounting

RADIUS provides a means of accounting for the time and data consumed by users. It does this following various RFCs in order to be compatible with other vendors of similar products. Unfortunately, the meaning of what a client has sent versus what they received (in the form of Input or Output RADIUS attributes), can be reversed depending on vendor and configuration.

To maintain consistency, CoovaAAA now allows the option Reverse Accounting when editing an Access Point - which defaults to enabled for compatibility. When proxying, CoovaAAA will send the correct values (reversing them if required) per RFC 2866. For more information, see the CoovaAAA RADIUS requirements.

CoovaChilli Accounting

Yes, the default accounting in CoovaChilli is reversed from ChilliSpot and now less-than RFC compliant. This was done, believe it or not, for compatibility reasons. However, since the first “coova” version, accounting is reversible back with the swapoctets option. If you use the swapoctets option with CoovaAAA, be sure to un-check the Reversed Accounting option for the Access Point.

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!

In a previous post, the idea of using the Google Web Toolkit to create a new kind of embedded web administration interface for devices was discussed. I continue the discussion by providing some examples and a working demonstration of the user interface.

The interface is designed, in this case, to be the administrative web console of a OpenWrt-based firmware. As such, it is a tool to configure (linux) system parameters and files - which may be different depending on the underlying system. For instance, the WhiteRussian branch of OpenWrt use NVRAM settings while Kamikaze uses the new UCI Configuration.

Working with XML

The application in this example uses XML to define the system configuration and also to define the user interface to edit this configuration. XML is well suited for this purpose and offers many benefits, including:

• Easy to read and edit by hand
• System independence and interoperability
• Transformed into other formats using a structured language
• Excellent open-source libraries, tools, and resources

The well-formed structure of the XML resources are converted into JSON objects by a CGI program running the server-side of the application. The GWT interface exchanges JSON objects with this CGI back-end to load or save data.

Defining system configuration

The GWT-based user interface is designed as a configuration editor. The configuration itself is stored in XML as specified in the sysconfig DTD. The DTD defines how a system is configured and is used for basic syntax verification. Here is a portion of the “config.xml” system configuration based on this specification:

<sysconfig>
  <system>
    <settings boot_wait="true" hostname="Coova"/>
  </system>
  <network>
    <interface id="loopback" proto="static" .../>
    <interface id="lan" proto="static" .../>
    <interface id="wan" proto="dhcp" .../>
  </network>
  ...
</sysconfig>

The XML is transformed into JSON by the CGI program when sent to and stored by the GWT application (as a JSONObject), as shown in the “Status / Config Tree” tab of the demo.

Defining the user interface

The user interface screens are defined in XML based on the cap-ui DTD. The portion that builds the systems settings screen to configure the above XML segment is as follows:

<cap-ui>

  <menu name="System">

    <submenu name="Settings">

      <inputset name="System Settings" object="system.settings">

        <input label="Host Name" key="hostname">
        </input>

        <input label="boot_wait" key="boot_wait">
          <option name="Enabled" value="true"/>
          <option name="Disabled" value="false"/>
        </input>
        ...
      </inputset>
      ...
    </submenu>
    ...
  </menu>
  ...
</cap-ui>

Configuration transformations

Taking the XML configuration and using it to set the underlying system configuration is done using XSLT. Transforms take the XML and produce scripts for WhiteRussian (example) and Kamikaze (example), the output of which is shown in the “Status / Config Files” tab of the demo.

The demo

See an on-line demonstration of the user interface using something similar to the above configuration. Please, keep in mind it is still a work in progress and not all the screens and dependencies are defined. The configurations transforms are also incomplete - as is the UCI configuration of Kamikaze.

If you want to help out, come join the forum! (when your done helping out OpenWrt)

JRadius is a project I started to not only address the need for a Java RADIUS client capable of EAP-based authentication, but for a Java framework for processing RADIUS authentication and accounting through a server front end like FreeRADIUS. Why? Well, for several reasons. First, I primarily had Java programmers. But, also because Java offers a lot in terms of portability and integration with other Java components and systems. This article will help point you in the right direction to get up and running with JRadius in both the client and server context - there will be more articles and wiki documentation to come.

Using JRadius with FreeRADIUS

The first thing you need is a FreeRADIUS server with the JRadius module. Instructions on how to do this are here, in the wiki. The JRadius module, rlm_jradius, is what links the FreeRADIUS server to the JRadius server. Using pooled connections, requests are taken out of FreeRADIUS and passed on to JRadius for processing. The basic structure of a JRadius handler looks like:

public class MyHandler extends PacketHandlerBase {
public boolean handle(JRadiusRequest request) {
AttributeList ci = request.getConfigItems();
RadiusPacket req = request.getRequestPacket();
RadiusPacket rep = request.getReplyPacket();
String u = (String)req.getAttributeValue(Attr_UserName.TYPE);
…

}
}

From within the JRadius Java server, you are able to do just about everything any other FreeRADIUS module can do. This includes adding, removing, or altering attributes in the request, the reply, or the internal FreeRADIUS “config items” attribute list. The latter is used within FreeRADIUS - often using FreeRADIUS internal only attributes - to control the state and behavior of the request.

AttributeList ci = request.getConfigItems();
ci.add(new Attr_UserPassword("password"));

For instance, to give FreeRADIUS the plain text password of a user (to be used by FreeRADIUS during actual authentication), you might have the above in your authorize JRadius handler.

Running JRadius Server

To get your handlers up and running, you need a JRadius server. Instructions on how to build and get an example server running is found in the wiki. You can easily build from the JRadius SVN using Maven and Ant. Doing mvn install will setup the dependencies and create jar files in the typical target directory for core (core JRadius client and server), dictionary (attribute dictionary), extended (JRadius classes that require the dictionary), and example (a couple examples). Using Ant by doing ant dist will create just 2 jars in the dist directory - jradius.jar and jradius-dictionary.jar, where the former contains everything minus the dictionary. To summarize the steps in getting the JRadius example server running:

svn co http://dev.coova.org/svn/cjradius/
cd cjradius
ant dist
ant run-example

You can find the example source code in the java/example directory which can be extended to suite your specific needs.

Using JRadius Client

The Client API is simple and able to do a variety of authentication protocols - including PAP, MSCHAPv2, EAP-MD5, and EAP-TTLS/PAP. JRadius can be integrated into any Java authentication scheme. For instance, it has been used with Jive Wildfire and Shibboleth.

Development and Support

For questions, suggestions, bug reports, patches, and the like; I have created a JRadius Forum.