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.