SUBSCRIBE NOW!

Vol. 26 No. 3 — March 2006

One runs on open source; the other USES vendor software.

Every place has it—coffee shops, bookstores, universities … and now libraries just like yours are offering wireless Internet access too. If you do not have it, it is likely that your patrons are asking for it often. So what is holding you back?

At the Waterford Township Public Library, Andrew Mutch created a wide-open wireless network using Public IP open source software. About 20 miles away, at the Novi Public Library, Karen Ventura created an authentication-required wireless network using the Smart Access Manager Wireless Manager. Both networks allow library users to get online using their own laptops or other portable devices. We created the networks using two different technologies to meet the needs of two different libraries in two different communities.

The libraries in Waterford and Novi both belong to The Library Network (TLN) consortium, along with more than 60 others in southeastern Michigan. As members of the TLN Technology Committee, both of us share ideas with the techies at other public libraries regularly. Other TLN libraries had implemented wireless networks, each using a design that worked for its own community.

In this article, we will compare notes on how we made it happen in our libraries. This way you will get the benefit of reading about two different strategies at once. We believe you will find that creating a wireless hotspot in your library is more doable than you might think.

Andrew at Waterford: Wide Open Wireless

At Waterford, I was fortunate enough to be able to incorporate plans for a new public wireless network into a building expansion and renovation plan that was taking shape in fall 2003. The library hired a consultant who specialized in wireless networks to guide us through this process. The consultant designed the network, drafted an RFP for installation, and reviewed the bids that were submitted. He also oversaw the actual installation and testing of the network.

Setting Up the Hardware

I relied on the consultant to help me select the appropriate hardware for our network. He recommended Cisco Aironet 1200 wireless access points (WAPs). The WAPs we ordered came with 802.11b cards. In late 2003, 802.11b was the de-facto wireless protocol and it appeared that the majority of users would still be using 802.11b for the foreseeable future. (Since then, 802.11g has made its way into the consumer wireless market. Fortunately, most 802.11g cards are backward-compatible with 802.11b WAPs. The Aironet 1200s also can be upgraded by installing separate 802.11g cards.)

The Aironet 1200s also support Power over Ethernet (PoE). Devices that support PoE can be powered via a standard CAT 5 data cable through a special PoE injector, hub, or switch. This eliminates the need to run a separate power supply to the device. Using PoE access points allowed me to consider locations where extending power might have been problematic. It also gave me the future flexibility to move the WAPs if necessary.

We configured our WAPs to make it easy for patrons to find and join our network. We broadcast our service set identifier, or SSID, with the name “library” so that patrons’ computers and devices could locate our WAPs. We also disabled encryption on the WAPs. These measures made it more likely for patrons to be able to connect to our network without staff assistance.

Choosing and Configuring the Open Source Software

Once our consultant had completed the wireless network design, I was responsible for selecting the user authentication and management component. Initially, I had planned to include patron-specific authentication as part of our wireless system. But because we use a shared automation system provided by our library cooperative, authenticating patrons would have required coordination with the cooperative. At that time, prospects for authentication were uncertain due to the cooperative’s move to a new auto­mation system. So rather than put our plans on hold, I went back to my administrators and got the OK to explore a system that didn’t require patron-specific authentication.

After looking at several open source systems, I selected Public IP for our wireless authentication and management. Public IP is an open source solution that runs a modified version of the open source NoCat system. The Public IP system runs from a single computer or server, and its requirements are simple: a CD drive, a floppy drive or USB port, two network cards, and at least 256 MB of RAM (the more RAM, the better). I didn’t need any operating system; the Public IP CD includes its own Linux operating system.

I found that once I burned Public IP to a CD, starting and configuring it was straightforward. When the authentication/management computer is booted, it loads Public IP directly from the CD into virtual memory. The first time I started Public IP, I was asked a series of questions to configure the system. These configurations are then saved to the floppy disk or USB drive. On future system start-ups, Public IP loads the configurations from the floppy or USB without prompting. If I need to recover the system due to a lock-up, crash, or compromise, I just reboot the server. This method of recovery is so simple and painless that even nontechnical staff can do it.

How Waterford’s System Works Without Authentication

Public IP has two operational modes, closed and open. The closed mode requires users to register and authenticate with a remote server managed by Public IP. I use the open mode at Waterford, which allows users to join the network without creating a user account and without authenticating against the remote Public IP server. (Both modes support additional features including a network firewall and content filtering.)

While running Public IP in the closed mode offered us the option to register users, I decided that this approach would be a management headache for me and the library staff who would interact with patrons. Unlike systems that authenticated against our auto­mation system, I would have had to manage a separate user database of Public IP users. Also, I was leery of having the availability of the system being at the mercy of a remote server. While the Public IP developer has always been responsive, network hiccups and outages between my library and his server could easily leave my system offline even as the Public IP servers hummed away at their remote location. I also didn’t want to burden staff with troubleshooting user registration problems when I wasn’t available to assist.

Deciding to run Public IP in open mode and allowing patrons to connect to the network anonymously meant accepting some trade-offs. While it eliminated the need to authenticate users, it also eliminated any easy way to track users and abusers of the system. Public IP in open mode only presents a list of MAC addresses of devices currently connected through it; it does not provide the detailed statistics that are available to systems running in closed mode. But running in open mode does not mean anything goes on our network. We block ports that tend to be abused, and Public IP it­­self serves as a firewall, controlling traf­fic be­tween the wire­less network and our Internet connection.

Public IP manages the entire pro­cess of connecting the user to our network. When a patron’s lap­top or device first connects through an access point, Public IP assigns it an IP address but does not allow access to any Internet resources. The patron must open his Web browser and go to a site. Public IP then presents the user with our Internet Use Policy, which the user must view and acknowledge. Only then does Public IP grant full access to Internet resources.

Patrons Are Working on Their Own

Once the network was ready, I decided that a soft launch, where we turned on the system without a lot of fanfare, would be the best approach. It didn’t take long for patrons to discover our new wireless network on their own. Soon people were parked for hours at a time using the new network. After tweaking a few settings, I decided that the system was reliable enough that we could start advertising its availability on our Web site and in our literature. In the first month, Public IP only saw a handful of users. But each month, the numbers have continued to grow. Now it’s been up for a year and a half, and we average close to 200 users each month.

The vast majority of users get onto the network without any staff assistance. For those who need help, most get online after reviewing the literature that includes the details of our network settings. Occasionally, the authentication/management server locks up and has to be rebooted. But by and large, the system has operated trouble-free and the patrons have worked with little need for assistance from staff.

Karen at Novi: Restricted Wireless

The Novi library board had included a wireless hotspot in the library’s long-range plan, scheduled to be implemented in 2005. So over the past couple of years, I had been researching various solutions to provide wireless access in a secure and manageable way. Early in 2005, TLN started to organize a group purchase of the Smart Access Manager (SAM) from Comprise Technologies. Along with my systems administrator, Barb Rutkowski, and the rest of the library staff, I was planning for Novi to be one of the first TLN libraries to implement SAM.

Software to Manage Sign-Ups and Sessions

SAM would require library card authentication for all of our public computers. It would also manage the sign-ups and session time limits for them. Previously, the public users simply had to sign up with their first name on a clipboard at the Information desk, and the time limits were handled manually by the librarians. With SAM, patrons were going to need library cards (or visitor cards) to use a computer. This software uses the Standard Interchange Protocol, better known as SIP, to validate the library card and PIN authentication against the rec­ords in the library system database, which then builds a SAM database of authenticated users.

Barb and I had worked hard to create an integrated and manageable network structure for the technology at Novi. After looking at other stand-alone wireless network solutions, we learned that Comprise had recently in­troduced a wireless manager mod­ule that works with SAM. The SAM Wireless Manager requires library card authentication for all users that connect to the wireless network. In addition, it manages the public wired drops that we ad­ded to complement our wire­less network. By using this wireless manager module along with SAM, all Internet users would have the same experience at the library, regardless of which computer they used to connect. Therefore, we chose the SAM Wireless Manager for our wireless network. Since this product fit in so well with our existing technology structure, we were able to extend our existing Internet Access Policy to apply to our wireless network as well. Our procedures for the wireless network are not any different than those for our library computers.

How It’s All Hooked Up

The SAM Wireless Manager uses a Bluesocket Wireless Gateway device to manage the traffic. We selected the WG-400, which supports up to 50 concurrent users. Any wireless access point can be used for the infrastructure. We chose the 3Com 8250 WAP, which supports both 802.11b and 802.11g standards. A server hosts the SAM software, which manages the authentication using SIP and maintains the SAM database of users. In our case, the SAM server is shared by many TLN libraries and is housed at the cooperative offices.

Ultimately, here’s how our setup works: A user with a wireless-enabled device opens a Web browser in the library. The nearest WAP allows that user onto the library’s wireless network. The user’s Web browser is intercepted by the Bluesocket and re­directed to the SAM server for au­thentication. The user is prompted for his or her library card number and PIN. As with the library’s own computers, the SAM software validates the authentication against its database. Then the user is allowed onto the wireless network and redirected to our Web site, from which he or she can use the Internet.

On the library’s computers, the user’s experience is managed by the way the computer is set up. We install specific software and we lock down access to specific files and folders. We carefully include updated antivirus software and operating system updates. We work hard to minimize the amount of security threats that can jeopardize our library’s network. However, wireless networks are more difficult to manage because we have no control over how a user’s own computer is set up. Once on the wireless network, a user’s access is defined by the configuration we set on the Blue­socket Gateway. The Bluesocket can manage how much bandwidth is allotted to wireless network users in order to maintain equal access for all of them (those on the wireless network and those on our wired machines).

The Bluesocket can also allow or deny access to specific network ports so that we can control access to ports that can support malicious behavior. For Novi, we set up a configuration that supports general Internet ac­tivity (allowing access to HTTP, HTTPS, DNS, SSH, and many others) but limits access to ports that are often abused. It is a good idea to segment your wireless traffic onto a separate part of your network, or even onto a completely separate network. Some libraries have successfully put their wireless networks onto cable modem circuits. This ensures that any abuse will not interfere with your usual network operations. We did not set up our wireless network this way at Novi because the Bluesocket gives us control over access.

Launching, Then Aiding Users

We went live on our wireless network on Oct. 31, 2005. Adding any new technology service brings the question of how to support our patrons in using it. Wireless access was no different. Barb and I created a brochure with step-by-step instructions to help patrons log on to the wireless network. (You can see it on our Web site.) Even this was challenging, as all users’ computers are not set up in exactly the same way. But our brochure was a “getting started” guide, and problems specific to one person’s computer were his or her own responsibility.

At Novi, we were able to meet the demand for wireless access with a manageable solution that empowers our users. Their library cards authenticate them to use our Internet access in a responsible way. Even guests can get temporary access. Knowing that we have 200–250 users monthly on average, we believe our patrons are pleased.

Trying to Compare Apples and Oranges

As we look at these two different approaches to wireless hotspots, there are some obvious differences. The first is cost. Public IP is open source software, and therefore it is free. SAM costs money. At Novi, we had committed to the SAM software for our library computers, so extending it to the wireless network was not as costly as it would have been if we were starting from scratch.

The second major difference is authentication. With Public IP in open mode at Waterford, there is no authentication. There is no way to know who is using that wireless network at any given time. If staff members become aware of abuse while it is occurring, they might be able to take some action, based on the MAC address of the computer. With SAM at Novi, every user authenticates with a library card number. If those employees discover abuse on the network, they can link it back to the user, so there is accountability there. At Novi, we believe that requiring a login (even on our library computers) makes our users act more responsibly.

The third difference is in ease of use. When patrons are required to authenticate, it is more inconvenient for them. If they do not have a library card, then they have to talk to the staff before getting online. When users do not have to authenticate, they can get online much more quickly and easily.

Which is better? In the end, we honestly cannot make a firm recommendation for one or the other. It’s like comparing apples and oranges: Both are fruits with similar uses, yet they are completely different from one another. In our case, both wireless networks are working well in our different communities. Both networks are getting a lot of use, and everyone seems pleased that the network is available to them. These two designs are only two of many options available to libraries; solutions range in complexity and you just have to choose one that suits your needs and tastes.

If you are planning for wireless in your library, first answer some questions about your situation: How much of a budget do you have? Do you have a reason to require authentication? How will your wireless network fit in with the rest of your technology services? How do you want to handle any network abuse? How much will you assist your users on the wireless network? Then continue to read about your options and talk to others who have wireless networks already to find out what works well and what does not. We are also happy to talk with readers about this topic—feel free to contact us.