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!