Open Source Wifi Hotspot Implementation Tyler Sondag and Jim Feher The goal of this paper is to describe a design—includ- other hardware. The routing functions of the WRT54GS ing the hardware, software, and configuration––for an were not used in this implementation. The servers need not be anything special; older hardware will work just fine. For open source wireless network. The network designed will this implementation, decommissioned 900 MHz units with require authentication. While care will be taken to keep 512MB of RAM and 40GB hard drives were used. the authentication exchange secure, the network will oth- erwise transmit data without encryption. n Wireless router software ireless networks are an essential tool for provid- ing service for colleges and libraries. This paper In order to provide the functionality required, the units Wwill explain the setup of a wireless network had their firmware flashed with an open-source, Linux- using open-source software and inexpensive commodity based operating system available from OpenWrt for the hardware. Open-source software was employed exclu- Linksys routers (http://www.openwrt.org). Support is also sively. This allowed for flexibility in design and reduction available for other wireless devices. “The firmware from in expense while also providing a platform for students to OpenWrt provides a fully writable file system with pack- learn more about the internal workings of the system by age management. This allows developers the freedom to examining particular sections of code in which they have customize the devices by choosing only the packages and interest. Standard commodity hardware was used as a software that are necessary for their applications.”1 As the means of saving cost. This should allow others to repeat routers have limited storage, being able to hand select only this design with a minimum of funding. the necessary components is a definite advantage. The purpose of a network, like any resource, is to provide a service for those who own it; in this case, the patrons of a library, or students, faculty, and staff at a col- lege. To ensure that this network serves its owners, users n Server software will be required to authenticate before gaining access. Once authenticated, the central captive portal can pro- For the operating system on the servers, Fedora Core vide different levels of service for specific user groups, was chosen.2 Fedora provides the Yellow Dog Updater, including guest access, if desired. For this system, ease Modified (yum), which eases the updating of all pack- of access for users was the primary concern; other than ages installed on the system, including kernel updates.3 using the Secure Socket Layer for authentication, the This aids security by providing a platform for easily and remainder of the traffic was unencrypted. frequently updating the system. Fedora Core is an open- Other than the base nodes, the remaining access points source distribution that is available for free. Fedora Core were connected to each other using a wireless connection also comes with many other open-source packages that in order to avoid physically connecting all access points were used in this design, such as the Apache Web server. across campus and to further reduce the expense for the While the designers had more familiarity with Fedora, deployment of the network. This was accomplished using other distributions are also available that provide simi- the WDS (wireless distributed system) feature on the lar benefits (Suse, Ubuntu, OpenBSD, Debian, etc.). The wireless routers. All access points connect to a centralized server was run in command line mode with no graphical set of servers that provide: DHCP, Web-caching proxy, user interface in order to reduce the load on the server DNS caching, radius, Web server, a captive portal, and and save space on the hard drive. logging of network traffic. n Captive portal n Hardware In order to require authentication before gaining access Requirements for the network were relatively modest, to the network, a captive portal was used. Some of the using inexpensive wireless routers along with several Linux servers built upon older Pentium 3 desktop systems. Linksys WRT54GS routers were chosen as the access points as they are inexpensive, readily available, and possess the Jim Feher ([email protected]) is an Associate Professor ability to run custom open-source firmware. Other access of Computer Science at McKendree College in Lebanon, Illinois. points could be used; however, the configuration sugges- Tyler Sondag ([email protected]), is a senior in tions are specific to the WRT54GS and may not apply to Computer Science at McKendree College. OPEN SOURCE WIFI hotspot implementation | sondag AND feher 35 desired features in the choice of the captive portal were: to the rest of the network (appendix A). SSH login for root encrypted authentication, traffic logging, and the ability was also disabled at this time for added security. to provide different levels of service for different user groups. Logging traffic allows the system administrators to identify accounts that have been misusing the network. Those who inadvertently misuse the system or perhaps n Server #1 configuration have had their accounts compromised can have their access temporarily disabled until they can be contacted For server #1, very little setup was required. Since this with instructions concerning acceptable use of the net- server works mainly as a router, the only major items that work. As the network must be shared by all, those who went into its configuration were the iptables rules, which habitually abuse the resource can have their accounts per- are shown and described in appendix B.7 Rules were set manently disabled. The captive portal should also redi- up to: rect Web traffic to a login page that is served on the Secure Socket Layer until the user logs in. Chillispot was chosen n set up network address translation; as it possesses all of the features mentioned above.4 n allow traffic to flow within the network; n log the traffic from the wireless portion of the net- work; n allow for the transparent setup of the Web proxy n Server layout server; and n set up port knocking before allowing users to log into As can be seen in appendix A, three servers were used the router via SSH.8 for this implementation. The first server was used as the main router to the Internet. The second server ran A reference to this script was placed in the /etc/rc.d/ a Squid Web caching server.5 It also ran a DNS cach- rc.local file so that it would run when the server boots. ing server and the FreeRADIUS server.6 The third was Last was the setup of the three network interfaces in used for the captive portal. Three servers were used for the machine. This can be done during system installation various reasons. First, this distributed the load. Second, or afterwards on the Fedora Core based server by editing portions of the network that were not behind the cap- the configuration files in the /etc/sysconfig/networking- tive portal could more easily use the services on the scripts/ directory. One of the configuration files used in second server running Squid, DNS, and FreeRADIUS. It this implementation can be seen in appendix C. Of course should be noted that three independent servers are not the configuration will change as the topology of the net- required; many of the services could be consolidated on work changes. two or even one single server to reduce the hardware requirements. The implementation depends upon the specific needs for the network. n Server #2 configuration The second server required significantly more setup to n Server installation configure all of the necessary services that it runs. The first service added for this implementation was the Web- Installing the operating system (Fedora Core) on each caching proxy server, Squid. Squid’s default configura- server is a relatively straightforward procedure. Each tion file (/etc/squid.conf) is quite large; fortunately it machine was partitioned with 1024 MBs of swap space requires little modification to get a simple server up and with the rest of the drive being an ext3 partition with running.9 The changes made for this implementation can the mount point “/”. Only the minimal set of packages be seen in appendix D. The most important lines in this required were installed at this time. The first server, configuration are the last few, which enable it to act as a server #1 (router), was given three network interfaces, transparent proxy server, making it invisible to the users one for the Internet connection, one to connect to a switch and requiring no setup of their browsers. that then connects to server #2 (Web/DNS caching and As there was no need for an authoritative DNS server, radius) as well as other machines that do not connect just DNS caching for the network, dnsmasq, which is through the captive portal, and one connecting to server easy to configure and can handle both DHCP services as #3 (captive portal machine). The second server, server #2, well as DNS caching, was chosen.10 In this instance, the only needs one interface, but the third, server #3, requires captive portal was used to provide DHCP services for the two interfaces, one for the master wireless access point, wireless clients; however dnsmasq was used for dynamic and one to connect to the switch connecting this machine clients on the remaining portion of the network. Dnsmasq 36 INFORMATION TECHNOLOGY AND LIBRARIES | jUNE 2007 is relatively easy to configure, requiring only one change be configured and copied to the proper directory, the in its default configuration file, which points to the file in main configuration file and the login file.