WiFi Roaming

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.