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.

With Coova, you can pick and choose the software and services you need - depending on the kind of network you are building and how you want to access it. Here are some typical uses of Coova technologies:

• Use CoovaAP for easy configuration of CoovaChilli (or WiFiDog):
  • with or without using CoovaAAA services,
  • using RADIUS or locally defined users,
  • using the customizable “Internal” captive portal, or
  • configured to use your own portal or RADIUS service.
• Use CoovaChilli either in CoovaAP or in your own firmware or server to:
  • enforce a captive portal and authentication using CoovaAAA or any other portal/RADIUS service,
  • works with a variety of commercial services (ask your provider),
  • integrate with 802.1X authentication to provide accounting and access limitations.
• Use CoovaAAA to manage the access to your network:
  • with a CoovaChilli/AP captive portal,
  • using a patched WiFiDog captive portal,
  • using your own captive portal (no advanced programming needed),
  • using our Facebook or standard captive portal applications,
  • using a commercial access controller (like Colubris), or
  • using any router supporting WPA Enterprise/802.1X (like the AirPort Extreme).
• Use and share your CoovaAAA controlled network:
  • using one account to login to both your captive portal and your secure WPA Enterprise networks (using any device supporting 802.1X, like your laptop or Nokia phone),
  • using your account at any CoovaAAA location that is being shared with you,
  • selectively share your network with only those you choose - individuals or entire realms, or
  • share your network based on OpenID logins or Facebook fans/friends.
• Use CoovaFX and CoovaSX in Firefox or your phone, respectively, to login past a captive portal using the WISPr standard and a pre-configured account - WISPr is supported by CoovaAAA and most commercial access controllers and service providers.

• Use JRadius to program your own RADIUS provisioning logic for your network.

If you are building a WiFi network and haven’t found anything on this site that can help you, you probably haven’t looked hard enough. Though, it has been said, and we do acknowledge, that more documentation is needed. For this, we call out to the development and user community to help out in the Wiki (click on the “* wiki” to create an account and login), forums, and mailing lists. Note: In the Wiki, we do lock pages to prevent SPAM - either create a new page or ask for more permissions on one of the mailing lists.

We are also hoping to hear more about how and where you are using Coova! In fact, a friend of mine was recently vacationing in the Dominican Republic and was pleasantly surprised to find a Coova signal at the Hotel. They were using CoovaAP for their WiFi. Stories like this are terrific — lets get them in the forum!

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 …

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).

]]> http://coova.org/wordpress/index.php/2008/03/30/project-news/feed/ http://coova.org/wordpress/index.php/2008/03/06/for-firefox-users/ http://coova.org/wordpress/index.php/2008/03/06/for-firefox-users/#comments Thu, 06 Mar 2008 16:05:13 +0000 david Releases Applications http://coova.org/wordpress/index.php/2008/03/06/for-firefox-users/ 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:

]]> http://coova.org/wordpress/index.php/2008/03/06/for-firefox-users/feed/ http://coova.org/wordpress/index.php/2008/01/25/dhcp-discovery/ http://coova.org/wordpress/index.php/2008/01/25/dhcp-discovery/#comments Fri, 25 Jan 2008 13:14:38 +0000 david Development http://coova.org/wordpress/index.php/2008/01/25/dhcp-discovery/ 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!

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!

• 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.

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.

CoovaChilli 1.0.9 has been released. This is largely a bug fix release, see the ChangeLog for details. Binaries for more systems will be available soon.

CoovaAP 1.0-beta.7 has also been released, with the following highlights:

• CoovaChilli 1.0.9
• Facebook HotSpot configuration
• Notes on Upgrading from previous version

As promised, this version allows for easy configuration for the Coova HotSpot captive portal application on Facebook.