Wireless Portals with Wifidog
It has become commonplace for most major cities to have a Wi-Fi group. The Wireless Community movement has spread across North America, Europe and has extended to Latin America and Asia. Hackers world-wide haven't been able to keep their hands off low-cost, easily extensible hardware. Some Wi-Fi groups get together and share technical information and war-driving data, and other groups work on projects setting up ad hoc mesh networks or creating free hotspots in their favorite hangouts.
Two years ago, in an event similar to what has taken place in many other cities, a group of Montréal technology enthusiasts got together and decided to start creating free hotspots for themselves and for other Montréalers. People joined the group after hearing about it through the local open-source grapevine. Calling themselves Ile Sans Fil (French for “Wireless Island”—and, yes, Montréal is an island), they are now one of the more active established Wi-Fi groups in the world, with 25–35 active volunteers, 50 hotspots and 6,000 users. Their current rate of expansion is 4–8 hotspots and 1,000 users per month. Based on the number of users, this volunteer group is the most successful of the seven Wi-Fi companies operating in that area.
Ile Sans Fil (ISF, www.ilesansfil.org) was able to get a quick start on the project by using a popular open-source captive portal called NoCat, which did a good job of allowing only users from a list of user names and passwords through. A captive portal is a dynamic firewall in which all traffic is blocked until the user logs in (or a disclaimer page was displayed and terms of service were agreed to). The login page works by intercepting http traffic and, in its place, displaying a form until the user is validated. Once logged in, some, or all, ports work normally. By nature, all captive portal authentication solutions are vulnerable to MAC address spoofing, and as such, these are not bulletproof. However, they have the huge advantage of not requiring any software beyond a Web browser to perform sign-on.
Fortunately, two years ago a wireless router running Linux became available (the Linksys WRT54G). It wasn't advertised as running Linux, but the Seattle Wireless group discovered this, and the hacking began. ISF finally had an inexpensive embedded platform to move to. They chose OpenWRT as a distro, but NoCat and its dependencies just wouldn't fit.
And so the Wi-Fi Guard Dog captive portal system was born. Like NoCat, Wifidog (www.wifidog.org) consists of two parts: a gateway per hotspot running a client process and a Web-based central server (Figure 1).
The Wifidog gateway is written in C with no dependencies beyond the kernel. A working gateway install can be packaged in less than 15Kb on an i386 platform. It works well on the MIPS-based WRT54G running OpenWrt. The Wifidog central server is written in PHP and handles authentication and manages the network. The system knows which hotspots are up through heartbeating from the gateway.
The gateway remains small and simple by delegating all cryptography to the user's Web browser and the auth server. Tokens are generated by the auth server upon successful authentication and are then sent to the gateway. The gateway then validates the token with the auth server. Tokens are revalidated periodically in case they expire.
How secure is it? The gateway never sees the password. The token itself is transmitted in the clear between the gateway and the auth server. It would be quite simple to encrypt this, but it has been deemed unnecessary bloat, considering that it's a one-time-use token and that to do a man-in-the-middle attack on it, an attacker needs to be between the gateway and the auth server, in which case the attacker already has Internet access, making the whole attack pointless. A much more realistic attack is MAC address spoofing, which is inherently easy to do with any captive portal software running on an open Wi-Fi network. The only solution for this is to use WPA. Unfortunately, tech-support realities make it completely unrealistic to require this until every platform has a central place to enter the necessary information (not to mention that many drivers still don't support it). The team will eventually move toward 802.11i once support for the standard improves.
Of course, the Wifidog auth server handles user authentication (currently, plugins exist for internal authentication and for authenticating to a remote radius database, including logging the amount of traffic transfered by each client). But the auth server does much more than that. It handles user sign-up, real-time network monitoring, extensive statistics about network usage patterns and hotspot popularity.
With Wifidog, the volunteer group had an easy way to continue deploying hotspots while minimizing the time spent on support.
However, although this technically has been a successful project in creating another open-source captive portal solution, it is only half the story. From the beginning, ISF viewed setting up free hotspots as only a first step. The volunteers now had the tools to draw laptop users from their basements and home offices into public spaces. The next step of the project was to use the network of hotspots to help create a sense of local community.
One way in which that is done is through the promotion of local content. A unique feature of the Wifidog system is its extensive support for location-specific content. Users connecting from Café Laika see an entirely different splash page and portal page than users connecting from Atwater Library. At first, the only form that local content took was HTML and RSS feeds tied to a hotspot. Fortunately, some of the hotspots had their own RSS feeds from their Web sites.
Through working with a local new media arts group, the local content feature recently was extended, so that now there is a system that also can manage text, images, audio, video and photos from Flickr (by using the Flickr API). All of this content can be sent across the network or sent only to select hotspot portals. The extensive logging functions also allow the group to show content to a user only once, only once per hotspot, once per day. It has certainly allowed these artists some interesting and unique possibilities for location-based art.
Another feature is the ability to see who else is on-line at a hotspot (either locally or remotely) and find out more about them if they have filled out their profile. Profiles are an opt-in feature and not only because the group doesn't want to annoy its users. The geographical proximity of users (in the same hotspot) raises certain safety and privacy issues that don't exist in most instances of social-networking software.
This past summer has been gratifying for the developers as their project has drawn the eyes of many wireless groups all over the world. Among the groups adopting it are WirelessLondon, New York City Wireless and Paris Sans Fil. WirelessLondon has recently started to use the Wifidog gateway with their existing central server. Jo Walsh—member of the group and co-author of the recent O'Reilly book Mapping Hacks—writes, “We found it easy to customize for our needs; we adapted our portal service to it in half an hour. The presence of an active and committed development community around Wifidog is reassuring; we know it won't go away, and the community's been gracefully receptive to our suggestions.”
Dana Spiegel—the executive director of NYCwireless—talks about his organization's impending trial of the captive portal, “NYCwireless is using the software in a pilot project and hopes to deploy it by the end of the summer to help local hotspots showcase local talent, multimedia sharing, art and student works. [Wifidog] is a great collaborative effort to provide a useful solution for community wireless networks. It enables the creation of a supported wireless network with community-oriented and created content, and really demonstrates how these networks and groups provide an important service to local areas.”
The group has not been surprised by the success. Benoit Grégoire, one of the lead developers of the group, says, “We designed Wifidog to be the Swiss Army knife of captive portal systems. We hoped that it could meet the needs of most wireless community groups well enough that they would prefer to help with its development rather than roll their own. Now we're seeing some of the realization of that goal.” The world of Wi-Fi community groups is starting to agree with them. What remains a question is how these other groups will use Wifidog for their own networks and in their own communities. From finding ways to make the software work (and make sense) in a mesh network, to developing GIS applications, to adding chat functionality to the network, there's lots of promising community and social applications for what was originally an infrastructure project.
Beyond the interesting technical possibilities, it is the chance to have an impact on the lives of their fellow citizens that seems to motivate Wifidog developers the most. With 10,000 users expected by December 2005 in Montréal alone, there is a good chance that their code will be used by neighbors, coworkers and friends. That, combined with the frequent press coverage and the chance to work with people they wouldn't normally meet, such as artists and community activists, means the team's energy and enthusiasm should remain high for the foreseeable future.
Michael Lenczner is a volunteer with Ile Sans Fil. He has been working in community informatics for eight years, both in Canada and abroad. He blogs at mtl3p.ilesansfil.org.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
3 hours 36 min ago
- Please correct the URL for Salt Stack's web site
6 hours 47 min ago
- Android is Linux -- why no better inter-operation
9 hours 3 min ago
- Connecting Android device to desktop Linux via USB
9 hours 31 min ago
- Find new cell phone and tablet pc
10 hours 29 min ago
11 hours 58 min ago
- Automatically updating Guest Additions
13 hours 7 min ago
- I like your topic on android
13 hours 53 min ago
- This is the easiest tutorial
20 hours 29 min ago
- Ahh, the Koolaid.
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?