It's simple to create a small, wireless network with an off-the-shelf wireless router. But providing industrial-strength wireless connectivity to an office, apartment building, or neighborhood is different. After you've done that, you're running a wireless Internet service provider (WISP). And to run a WISP you need to be able to answer questions like these:
- How good is my connectivity to the Internet right now?
- Which clients are associated to the network right now, and how good is their connectivity?
- Do I have adequate bandwidth for peak demand?
- Which clients associated recently, and how active were they?
- Which clients have solid connectivity and which are marginal?
- Do clients have many transmission errors and retries?
- Are upgraded versions of installed software packages available?
- Are big files taking up too much space?
- How can I simplify client administration?
In this article, you'll learn how to use Linux scripts to answer all of these questions. But before you can get started, you'll need to set up the server to run the show.
I became a wireless Internet service provider because my neighborhood had no DSL or cable Internet service. Another WISP provides (expensive) connectivity from a nearby mountaintop, so I decided to subscribe to that service and share the bandwidth and cost with my neighbors. An access point's wireless card generates a very weak signal, so to minimize signal loss I wanted the antenna cable to be as short as possible. I also wanted a high-gain outdoor antenna so I could reach as many neighbors as possible. These two requirements led me to mount the server outdoors on the antenna mast (see Resources for a link to a picture, and for information on all the products and packages I'll discuss in this article). My proof-of-concept server was an off-the-shelf wireless access point (WAP) mounted in a waterproof Pelican case. It wasn't very reliable, so I often had to climb onto my roof to tweak something. Those trips up and down the ladder convinced me that I needed to upgrade the access point to something more industrial-strength. My next-generation hardware would have to:
- be very reliable
- support ten clients plus some system management tools
- use a standard wireless card
- support power over Ethernet
- be Linux-friendly
I bought a low-cost board (in this case Soekris Engineering's net4521), which fit all those requirements and could use a compact flash card instead of a hard disk. This particular board also operated over a broad temperature range without a cooling fan.
A wireless card's chipset determines its Linux-friendliness, and the Intersil/Conexant Prism2/3 chipset has good Linux support.
Pebble Linux is a distribution designed especially for embedded wireless applications. It came by the name Pebble by being small and simple. It includes some nifty features such as:
- A kernel that is already customized for wireless use; no kernel recompiling is necessary.
- Its size; it's small enough to fit on a compact flash card, so you won't need a disk drive.
- It mounts its filesystems read-only, so there's no danger of corrupted filesystems if the power drops.
- Being based on the Debian Linux distribution, so Debian packages are available.
- It's well supported.
Pebble Linux includes many capable wireless packages, and it's easy to add more with Debian's apt-get capability. You might want to share the workload by putting some packages (for example, ntop) on a different server. But these packages can run happily together with ten clients on one board without taxing its processor or memory. Here are a few open source packages I recommend:
- Wonder Shaper, to ensure that clients share bandwidth equitably
- The Wireless Tools (WT), for talking to the wireless driver
- Host AP, the wireless access point software for Prism2/3 chipsets
- pcmcia-cs, to manage the wireless card
- logrotate, to compress or delete logs
- Net-SNMP, to collect router output
- ntop, for graphical utilization statistics
- iptables, as a firewall
You can find links to all of these packages in Resources.
Linux wireless management scripts you need
Packages give you the basic tools to get your wireless network up and running on Linux. From that point on, keeping things running smoothly can either be a headache or it can be a pleasure if you have tools that help you:
- manage your server
- manage your clients
- manage your bandwidth
To meet these needs, I wrote a number of scripts to serve as tools; these are all accessible from a bare command line. Linux has a good implementation of the secure shell (SSH) server, so I can manage the server from anyplace that has Internet connectivity.
Linux distributions typically include some simple, but powerful, management tools. I couldn't live without the following:
- df gives space utilization information about each filesystem. This is especially helpful when your filesystems have limited free space.
- top gives a snapshot of your server -- information about uptime, CPU utilization, memory utilization, and processes.
- pstree offers a snapshot of your server's processes. It's easy to understand because the processes are displayed hierarchically.
My WAP has a read-write filesystem in memory for work files and logging. This allows the compact flash card's filesystem to stay in read-only mode. I wrote some scripts to manage this limited space.
bigfiles: The bigfiles script identifies files that might need to be pruned to avoid running out of space. It summarizes space utilization at three levels:
- Filesystem: How big is the filesystem overall and how much of it is free?
- Directory: How much space is each directory in the filesystem using?
- File: Which files in the filesystem are larger than 90 KB?
The output looks like this:
Listing 1. Output from bigfiles script
------------------------------------------------------------------------------ Filesystem Size Used Avail Use% Mounted on tmpfs 10M 952k 9.0M 10% /rw Finding big files in /rw filesystem... 916k ./var 4.0k ./usr 0 ./tmp 8.0k ./root 24k ./etc 0 ./dev 952k . 952k total ./var/log/router ./var/log/messages ------------------------------------------------------------------------------ |
checkspace
The checkspace script runs hourly and maintains a minimum amount of free space on the read-write filesystem. If more than 80 percent of the filesystem is full, checkspace runs logrotate, which compresses and prunes log files as necessary.
aptgetupgrade: The aptgetupgrade script checks for new packages or performs needed upgrades. It's a simple wrapper for the Debian apt-get command that can be run by /etc/cron.daily to help you keep your patches current.
Wireless clients will have questions, and the Linux-based management tools I'll discuss in this section will help you answer them. Here are some quick examples of how you can answer typical user questions:
- Question: "Is the Internet down today? Why can't my browser find www.flakyhost.com?"
- Solution: First, check your wireless network with the scanap script; it will tell you about the wireless signal quality of all associated clients, including the one that's giving you problems. Then, check IP connectivity with the pingall script; it will tell you about the latency to your ISP's gateway, the DNS, and all your clients, including the problematic one. If these two scripts establish that your network is OK, try www.flakyhost.com.
- Question: "Yesterday I downloaded from www.flakyhost.com at speed X. Why do I only get speed Y now?"
- Solution: To determine if your network is saturated, run the countlog script. It will tell you the day's transaction load history by client and by hour.
To promote simplicity and security, you might want to try the approach I take with my users. I have a MAC address for each client, so only those known MAC addresses are allowed to associate wirelessly. I give each client a fixed IP address, so only those known IP addresses are allowed through the router. Keeping all the information about clients in one place is much easier than synchronizing and duplicating config files. I assign each client's IP address a mnemonic hostname in /etc/hosts and I put the client's MAC address on the same line. For example:
Listing 2. Assigning a hostname and MAC address
192.168.168.198 wet11two 00:0C:41:BE:BF:B0 |
See Resources for a link to a sample version of /etc/hosts.
networkingrestart: The networkingrestart script starts networking and authorizes all valid clients. It reads the multipurpose /etc/hosts file, then adds the MAC addresses to the wireless access control list.
gethost: When you pass an IP address, host name, or MAC address to the gethost script, it returns all three from the multipurpose /etc/hosts file. The gethost script is used by the countlog, pingscan, and scanap scripts, and is also handy from the command line.
scanap: The scanap script displays the IP address, MAC address, name, and signal quality of each client associated to the AP. It reformats the output of The Wireless Tools' iwlist and adds the MAC address so each client's status is summarized in one line. Its output looks like this:
Listing 3. scanap script output
-------------------------------------------------------------- MAC Address...... Quality Signal Noise. IP Address....... Name 00:0C:41:BE:BF:B0 238/92 -29 -35 192.168.168.198 wet11two ------------------------------------------------ |
A WISP is subject to all the complexities of a wired network, along with other complications that are specific to the wireless environment. The following scripts help ensure that the bandwidth you deliver is stable and fast.
errors: The errors script pulls accumulated statistics from Linux's /proc/net/ and gives a snapshot of the overall transaction error rate for the access point. It also logs the output to a spreadsheet file for subsequent analysis. Its output looks like this:
Listing 4. errors script output
------------------------------------------------------ 13 22:20 TX Octets: 294080 TX errors: 1665 TX error ratio: 176 13 22:20 RX Octets: 893539 RX errors: 3225913 RX error ratio: 0 ------------------------------------------------------ |
This example indicates that the number of packets that transmitted successfully on the first try was 176 times greater than the number of packets that needed to be retransmitted. It also shows more errors than successes on the received packets. These numbers are only indicators to watch, so don't panic if they aren't consistent. Usage dramatically affects these ratios. With zero usage, there would be no successful packets, so the ratio would be zero. With low usage, the ratio will be low. With high usage, the ratio should be dramatically higher.
pingscan: The pingscan script measures latency, which indicates whether the client has fast and reliable throughput. It sends the client four short pings (56 bytes each) and four long pings (1,024 bytes each), then returns the following information in one line:
- Host name or IP address of the client
- Timestamp
- Number of replies received to short pings
- Number of replies received to long pings
- Number of replies to short pings that took over a second
- Number of replies to long pings that took over a second
It also logs the results to a spreadsheet file for subsequent analysis. In the output shown in Listing 5, the host was performing well. Replies came back from all four short pings and all four long pings. No replies took more than a second.
Listing 5. pingscan script output
------------------------------------------------------- wet11two,2005-03-18,23:59,4,4,0,0 ------------------------------------------------------- |
The next sample output listing was taken a day later. On that day the same host was missing some replies -- only one out of four short pings and three out of four long pings replied.
Listing 6. A sample pingscan script output
------------------------------------------------------- wet11two,2005-03-19,23:59,1,3,0,0 ------------------------------------------------------- |
If other clients were performing well (4,4,0,0), then this host was experiencing a problem. On the other hand, if multiple clients were missing replies, the problem was at the access point.
It is useful to know how much traffic is passing through your AP. One way to do this is to log the router's traffic through the System Network Management Protocol (SNMP), then count the log records. Different routers log transactions differently, so your mileage will definitely vary.
I configured my router to send its SNMP records to the IP address of a collector host (which in my case is the AP). On the AP, I run the snmpd and snmptrapd daemons to collect the records into a file. These records look like this:
Listing 7. Record collection
"@out 192.168.168.192 2983 208.222.234.90 80." "@in 211.107.232.1 51550 192.168.168.196 21." |
The outbound record is a Web request from 192.168.168.192 to 208.222.234.90. The inbound record is an FTP request from 211.107.232.1 to 192.168.168.196.
You can parse out a lot of useful information from this file -- virus probes that you may want to block, for instance. The countlog script counts these inbound and outbound records in two different ways. It can count the number of requests in the last n minutes, with n being a number that you can define:
Listing 8. countlog script counting requests in n minutes
Checking 5 minutes before 23:59... 101 requests in 5 minutes An average of 20 requests per minute |
It can also count the number of requests over the past 24 hours:
Listing 9. countlog script counting requests over 24 hours
Start... Total Outbound and Inbound Today 00:00... out: 192 in: 63 out/min: 3 . . . 19:00... out: 243 in: 96 out/min: 4 20:00... out: 308 in: 66 out/min: 5 21:00... out: 151 in: 103 out/min: 2 22:00... out: 206 in: 94 out/min: 3 23:00... out: 160 in: 70 out/min: 2 Totals.. 2095 1759 IP Address (Host Name) Total Outbound Today 192.168.168.8 (cheltenham) 659 192.168.168.191 (t30lan) 156 192.168.168.192 (downstairs) 1044 192.168.168.196 (opteron) 236 Total all IP's.... 2095 |
A few command-line shell scripts make it much easier to manage a WISP. Just a few final tips:
- Don't use USB wireless bridges at the client end. Their power is marginal, and they can't be pinged when the client computer is turned off.
- Don't try to run a big wireless network through a cheap home router. Doing so will cause unpredictable results.
With the tools and techniques outlined here, though, you should now be ready to get set up and running.
- See the author on one of his many climbs to the roof.
- The Pelican case keeps out the elements.
- Learn more about power over Ethernet.
- The Soekris Engineering net4521 board served as the basis for the solution described in this article.
- If you want to find out how various wireless cards fare under Linux, check out Jean Tourrilhes' page dedicated to the subject. Here you can find information specifically about the Prism2 card used in this article.
- Pebble Linux is designed specifically for embedded devices. It's based on Debian, so you can make use of apt-get.
- The packages listed in this article include:
- Download the scripts discussed in this article:
- Get a sample of the multipurpose /etc/hosts file.
- Check out "Exploring a significant business opportunity: The public wireless local area network," an IBM Global Services whitepaper written by Jyrki Korkki. (Document is in PDF format.)
- "Linux wireless networking" (developerWorks, March 2004) explains wireless networking with WLAN, Bluetooth, GPRS, GSM, and IrDA from a Linux perspective.
- Subscribe to the Linux Line Newsletter.
- Get involved in the developerWorks community by participating in developerWorks blogs.
Since 1999, Alan Baker has been a system administrator for numerous Linux servers, including dial-up, mail, Web, and wireless. He became a wireless Internet service provider in 2003. Strangely enough, he enjoys making systems secure and automating Linux system administrator tasks with small bash scripts.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags