Building Wireless Community Networks Implementing The Wireless Web 1st Edition Rob Flickenger
Building Wireless Community Networks Implementing The Wireless Web 1st Edition Rob Flickenger
com
https://ebookgate.com/product/building-wireless-community-
networks-implementing-the-wireless-web-1st-edition-rob-
flickenger/
OR CLICK BUTTON
DOWLOAD EBOOK
https://ebookgate.com/product/wi-fi-handbook-
building-802-11b-wireless-networks-1st-edition-frank-ohrtman/
ebookgate.com
https://ebookgate.com/product/deploying-wireless-networks-wilton-a/
ebookgate.com
https://ebookgate.com/product/wireless-broadband-networks-david-t-
wong/
ebookgate.com
https://ebookgate.com/product/wireless-sensor-networks-1st-edition-
liam-i-farrugia/
ebookgate.com
Wireless Web Development 2nd Edition Ray Rischpater
(Auth.)
https://ebookgate.com/product/wireless-web-development-2nd-edition-
ray-rischpater-auth/
ebookgate.com
https://ebookgate.com/product/wireless-broadband-networks-
handbook-1st-edition-john-r-vacca/
ebookgate.com
https://ebookgate.com/product/applied-optimization-methods-for-
wireless-networks-hou-y-t/
ebookgate.com
https://ebookgate.com/product/802-11-wireless-networks-the-definitive-
guide-1st-edition-matthew-gast/
ebookgate.com
https://ebookgate.com/product/linux-server-hacks-1st-ed-edition-rob-
flickenger/
ebookgate.com
Building Wireless Community Networks
Rob Flickenger
Publisher: O'Reilly
First Edition January 2002
ISBN: 0-596-00204-1, 138 pages
Building Wireless Community Networks offers a compelling case for building wireless networks on a local level: They are inexpensive, and they can
be implemented and managed by the community using them, whether it's a school, a neighborhood, or a small business. This book provides all the
necessary information for planning a network, getting all the necessary components, and understanding protocols that you need to design and
implement your network.
Building Wireless Community Networks
TABLE OF CONTENTS
Preface....................................................................................................................................4
Audience .............................................................................................................................4
Organization........................................................................................................................4
Typographical Conventions ................................................................................................5
Acknowledgments...............................................................................................................6
Page 2
Building Wireless Community Networks
Appendix ..............................................................................................................................91
A.1 Path Loss Calculations ...............................................................................................91
A.2 Links to Community Wireless Sites ..........................................................................92
A.3 FCC Part 15 Rules......................................................................................................92
A.4 Simple Scheme Management.....................................................................................96
Colophon ..............................................................................................................................97
Page 3
Building Wireless Community Networks
Preface
Building Wireless Community Networks is about getting people connected to one another.
Wireless technology is being used right now to connect neighborhoods, businesses, and
schools to the vast, massively interconnected, and nebulous entity known as the Internet. One
of the goals of this book is to help you get your community "unplugged" and online, using
inexpensive off-the-shelf equipment.
A secondary but critical goal of this book is to come to terms with exactly what is meant by
community. It might refer to your college campus, where many people own their own laptops
and want to share files and access to the Internet. Your idea of community could encompass
your apartment building or neighborhood, where broadband Internet access may not even be
available. This book is intended to get you thinking about what is involved in getting people
in your community connected, and it will demonstrate working examples of how to make
these connections possible.
Audience
This book describes some solutions to the current (but rapidly changing) problem of building
a wireless network for community use. It is not intended to be a design guide for wireless
companies and ISPs, although I hope they find the information in it useful (and at least a little
bit entertaining).
This book is intended for the technical user who is interested in bringing wireless high-speed
network access to wherever it's needed. This could include extending Internet connectivity to
areas where other access (such as DSL or cable) isn't available. It could also include setting
up access at a school, where structures were built long before anyone thought about running
cables and lines into classrooms. This book should also be useful for people interested in
learning about how dozens of groups around the planet are providing wireless access in their
own communities. The story of wireless network access is still in its infancy, but it is already
full of fascinating twists and turns (never mind its potential!). I hope to communicate what
I've learned of this story to you.
Organization
Early chapters of this book introduce basic wireless concepts and essential network services,
while later chapters focus on specific aspects of building your own wireless network.
Experienced users may prefer to skip around rather than read this book from cover to cover,
so here's an overview of each chapter:
• Chapter 1, gives a brief history of the state of wireless connectivity and some ideas
(and warnings) about how things might proceed.
• Chapter 2, is an overview of many important logistical considerations you will face in
designing your own network; it describes some tools that may make your job easier.
• Chapter 3, provides a detailed description of critical network components that you
will need to provide to your users. Network layout and security are also addressed.
• Chapter 4, details how to use wireless access point hardware effectively.
• Chapter 5, is a step-by-step guide to building your own access point using Linux,
inexpensive PC hardware, and conventional wireless client cards.
Page 4
Building Wireless Community Networks
Typographical Conventions
Italic
Used to introduce new terms, to indicate URLs, variables or user-defined files and
directories, commands, file extensions, filenames, directory or folder names, and UNC
pathnames.
Constant italic
Indicates a tip.
Indicates a warning.
Page 5
Building Wireless Community Networks
Acknowledgments
I would like to thank the O'Reilly Network Team, my parents, and especially Cat for their
endless encouragement and keeping me sane (and, in some cases, even sensible).
Also, my sincere thanks to Schuyler Erle, Adam Flaherty, Nate Boblitt, and Jim Rosenbaum
for helping to turn the NoCat idea into an actual living project. Thanks as well to Matt
Peterson, Matt Westervelt Adam Shand, Terry Schmidt, and the countless other pioneers of
ultra-hyper-connectivity.
Thanks go to the reviewers and read early drafts and made comments: Mike Bertsch, Simson
Garfinkel, Justin Lancaster, Nicholas Maddix, and Matt Peterson. Thanks also go to all the
people at O'Reilly & Associates who turned this manuscript into a finished book: Sue Miller,
my editor; Leanne Soylemez, the production editor; graphic artist Rob Romano; Catherine
Morris, copyeditor; and Mary Anne Weeks Mayo, who provided quality control.
Page 6
Building Wireless Community Networks
Never before have so many had free and fast access to so much information. As more people
get a taste of millisecond response times and megabit download speeds, they seem only to
hunger for more. In most places, the service everyone is itching for is DSL, or Digital
Subscriber Line service. It provides high bandwidth (typically, anywhere from 384Kbps to
6Mbps) over standard copper telephone lines, if your installation is within about three miles
of the telephone company's CO, or central office (this is a technical constraint of the
technology). DSL is generally preferred over cable modems, because a DSL connection
provides guaranteed bandwidth (at least to the telephone company) and thus is not directly
affected by the traffic habits of everyone else in your neighborhood. It isn't cheap, ranging
anywhere from $50 to $300 per month, plus ISP and equipment charges, but that doesn't seem
to be discouraging demand.
Telephone companies, of course, are completely enamored with this state of affairs. In fact,
the intense demand for high-bandwidth network access has led to so much business that
enormous lead times for DSL installations are now the rule in many parts of the country. In
many areas, if you live outside the perceived "market" just beyond range of the CO, lead
times are sometimes quoted at two to three years (marketing jargon for "never, but we'll take
your money anyway, if you like"). Worse than that, in the wake of widespread market
consolidation, some customers who were quite happy with their DSL service are finding
themselves stranded when their local ISP goes out of business.[1]
One currently circulating meme for this phenomenon deems a stranded DSL customer "Northpointed," in honor of the ISP
NorthPoint.net, which went out of business last March, leaving thousands without access.
What are the alternatives for people who want high-speed Internet access but aren't willing to
wait for companies to package a solution for them? The telephone companies own the copper,
and the cable companies own the coax.
Wireless networking now provides easy, inexpensive, high-bandwidth network services for
anyone who cares to set it up.
Approved in 1997 by the IEEE Standards Committee, the 802.11 specification detailed the
framework necessary for a standard method of wireless networked communications. It uses
the 2.4GHz microwave band designated for low-power, unlicensed use by the FCC in the U.S.
in 1985. 802.11 provided for network speeds of one or two megabits, using either of two
incompatible encoding schemes: Frequency Hopping Spread Spectrum (FHSS) and Direct
Sequence Spread Spectrum (DSSS).
In September, 1999, the 802 committee extended the specification, deciding to standardize on
DSSS. This extension, 802.11b, allowed for new, more exotic encoding techniques. This
pushed up the throughput to a much more respectable 5.5 or 11Mbps. While breaking
compatibility with FHSS schemes, the extensions made it possible for new equipment to
Page 7
Building Wireless Community Networks
continue to interoperate with older 802.11 DSSS hardware. The technology was intended to
provide "campus" access to network services, offering typical usable ranges of about 1500
feet.
It didn't take long for some sharp hacker types (and, indeed, a few CEO and FCC types) to
realize that by using 802.11b client gear in conjunction with standard radio equipment,
effective range can extend to more than twenty miles and potentially provide thousands of
people with bandwidth reaching DSL speeds, for minimal hardware cost. Connectivity that
previously had to creep up monopoly-held wires can now fly in through the walls with
significantly higher performance. And since 802.11b uses unlicensed radio spectrum, full-
time connections can be set up without paying a dime in airtime or licensing fees.
While trumping the telco and cable companies with off-the-shelf magical hardware may be an
entertaining fantasy, how well does 802.11b equipment actually perform in the real world?
How can it be applied effectively to provide access to the Internet?
An obvious application for 802.11b is to provide the infamous "last mile" network service.
This term refers to the stretch that sits between those who have good access to the Internet
(ISPs, telcos, and cable companies) and those who want it (consumers). This sort of
arrangement requires 802.11b equipment at both ends of the stretch (for example, at an ISP's
site and at a consumer's home).
Speaking of amplifiers, a related technical obstacle to wireless nirvana is how to deal with
noise in the band. The 2.4GHz band isn't reserved for use solely by 802.11b gear. It has to
share the band with many other devices, including cordless phones, wireless X-10 cameras,
Bluetooth equipment, burglar alarms, and even microwave ovens! Using amplifiers to try to
"blast" one's way through intervening obstacles and above the background noise is the social
equivalent of turning your television up to full volume so you can hear it in your front yard
(maybe also to hear it above your ringing telephone and barking dog, or even your neighbor's
loud television...).
If data is going to flow freely over the air, there has to be a high degree of coordination
among those who set it up. As the airwaves are a public resource, the wireless infrastructure
should be built in a way that benefits the most people possible, for the lowest cost. How can
802.11b effectively connect people to each other?
Page 8
Building Wireless Community Networks
In practice, many WISPs[2] are finding out that it's not as simple as throwing some antennas up
and raking in the cash. To start with, true DSL provides a full-duplex, switched line. Most
DSL lines are asymmetric, meaning that they allow for a higher download speed at the
expense of slower upload speed. This difference is hardly noticeable when most of the
network traffic is incoming (i.e., when users are browsing the Web), but it is present. Even
with the low-speed upload limitation, a full-duplex line can still upload and download data
simultaneously. Would-be wireless providers that build on 802.11b technology are limited to
half-duplex, shared bandwidth connections. This means that to provide the same quality of
service as a wired DSL line, they would need four radios for each customer: two at each end,
using one for upstream and one for downstream service. If the network infrastructure plan is
to provide a few (or even a few dozen) wireless access sites throughout a city, these would
need to be shared between all of the users, further degrading network performance, much like
the cable modem nightmare. Additional access sites could help, but adding equipment also
adds to hardware and operating costs.
Wireless Internet Service Providers. No, I didn't make that one up.
Speaking of access points, where exactly should they be placed? Naturally, the antennas
should be located wherever the greatest expected customer base can see them. Unless you've
tried it, I guarantee this is trickier than it sounds. Trees, metal buildings, chain link fences,
and the natural lay of the land make antenna placement an interesting challenge for a
hobbyist, but a nightmare for a network engineer. As we'll see later, a basic antenna site needs
power and a sturdy mast to mount equipment to, and, preferably, it also has access to a wired
backbone. Otherwise, even more radio gear is needed to provide network service to the tower.
Suppose that marketing has sufficiently duped would-be customers and claims to have enough
tower sites to make network services at least a possibility. Now imagine that a prospective
customer actually calls, asking for service. How does the WISP know if service is possible?
With DSL, it's straightforward: look up the customer's phone number in the central database,
figure out about how far they are from the CO, and give them an estimate. Unfortunately, no
known database can tell you for certain what a given address has line of sight to.
As we'll see later, topographical software can perform some preliminary work to help rule out
at least the definite impossibilities. Some topographical packages even include tree and
ground clutter data. At this point, we might even be able to upgrade the potential customer to
a "maybe." Ultimately, however, the only way to know if a particular customer can reach the
WISP's backbone over wireless is to send out a tech with test gear, and try it.
Page 9
Building Wireless Community Networks
So now the poor WISP needs an army of technically capable people with vans, on call for
new installations, who then need to make on-site calls to people who aren't even customers
yet. And if they're lucky, they might even get a test shot to work, at which point equipment
can finally be installed, contracts signed, and the customer can get online at something almost
resembling DSL. That is, the customer can be online until a bird perches on the antenna, or a
new building goes up in the link path, or the leaves come out in the spring and block most of
the signal (at which point, I imagine the customer would be referred to the fine print on that
contract).
I think you can begin to see exactly where the bottom line is in this sort of arrangement. It's
certainly not anyone's fault, but this solution just isn't suited to the problem, because the only
entity with enough resources to seriously attempt it would likely be the phone company. What
hope does our "wireless everywhere" vision have in light of all of the previously mentioned
problems? Perhaps a massively parallel approach would help....
The difficulties of a commercial approach to wireless access exist because of a single social
phenomenon: the customer is purchasing a solution and is therefore expecting a reasonable
service for their money. In a commercial venture, the WISP is ultimately responsible for
upholding their end of the agreement or otherwise compensating the customer.
The "last mile" problem has a very different outlook if each member of the network is
responsible for keeping his own equipment online. Like many ideas whose time has come, the
community wireless network phenomenon is unfolding right now, all over the planet.[3] People
who have been fed up with long lead times and high equipment and installation costs are
pooling their resources to provide wireless access to friends, family, neighbors, schools, and
remote areas that will likely never see broadband access otherwise. As difficult as the WISP
nightmare example has made this idea sound, people everywhere are learning that they don't
necessarily need to pay their dues to the telco to make astonishing things happen. They are
discovering that it is indeed possible to provide very high bandwidth connections to those
who need it for pennies—not hundreds of dollars—a month.
GAWD, the Global Access Wireless Database, lists 198 public wireless access points at the time of this writing. Check out
http://www.shmoo.com/gawd/ to add your own or search for one.
Of course, if people are going to be expected to run a wireless gateway, they need access
either to highly technical information or to a solution that is no more difficult than plugging in
a connector and flipping a switch. While bringing common experiences together can help find
an easy solution more quickly, only a relatively small percentage of people on this planet
know that microwave communications are even possible. Even fewer know how to effectively
connect a wireless network to the Internet. As we'll see later, ubiquity is critical if wide area
wireless access is going to be usable (even to the techno über-elite). It is in everyone's best
interest to cooperate, share what they know, and help make bandwidth as pervasive as the air
we breathe.
The desire to end this separation of "those in the know" from "those who want to know" is
helping to bring people away from their computer screens and back into their local
neighborhoods. In the last year, dozens of independent local groups have formed with a very
similar underlying principle: get as many people as possible connected to each other for the
lowest possible cost. Web sites, mailing lists, community meetings, and even IRC channels
Page 10
Building Wireless Community Networks
are being set up to share information about extending wireless network access to those who
need it. Wherever possible, ingeniously simple and inexpensive (yet powerful) designs are
being drawn up and given away. Thousands of people are working on this problem not for a
personal profit motive, but for the benefit of the planet.
It is worth pointing out here that ISPs and telcos are in no way threatened by this technology;
in fact, Internet service will be in even greater demand as wireless cooperatives come online.
The difference is that many end users will have access without the need to tear down trees and
dig up streets, and many others may find that network access in popular areas will be
provided gratis, as a community service or on a cooperative trust basis, rather than as a
corporate commodity.
The ultimate goal of this book is to get you excited about this technology and arm you with
the information you need to make it work in your community. We will demonstrate various
techniques and equipment for connecting wireless networks to wired networks, and look at
how others "in the know" are getting their neighborhoods, schools, and businesses talking to
each other over the air. Along the way, we will visit the outer limits of what is possible with
802.11b networking, how to stretch the range to miles and ways of providing access for
hundreds. If your budget won't allow for all of the networking gear you need, we'll show you
how to build some of your own.
Through the efforts of countless volunteers and hobbyists, more bits are being moved more
cheaply and easily than at any other time in history. There is more happening in the wireless
world right now than is practical to put down on paper. Get online and find out what others in
your area are doing with this technology (extensive online references are provided throughout
this book and in Appendix A).
I hope you will find this book a useful and practical tool on your journey toward your own
wireless utopia.
Page 11
Building Wireless Community Networks
The most common questions I've encountered about 802.11b networking seem to be the
simplest:
Of course, these questions have pat theoretical answers, but they all have the same practical
answer: "It depends!" It is easiest to explain how people have applied wireless to fit their
needs and answer these questions by way of example.
People are using 802.11b networking in three general applications: point-to-point links, point-
to-multipoint links, and ad-hoc (or peer-to-peer) workgroups. A typical point-to-point
application would be to provide network bandwidth where there isn't any otherwise available.
For example, suppose you have a DSL line at your office but can't get one installed at your
house (due to central office distance limits). If you have an unobstructed view of your home
from your office, you can probably set up a point-to-point connection to connect the two
together. With proper antennas and clear line of sight, reliable point-to-point links in excess of
20 miles are possible (at up to 11Mbps!).
The last class of networking, ad-hoc (or peer-to-peer), applies whenever an access point isn't
available. In peer-to-peer mode, nodes with the same network settings can talk to each other,
as long as they are within range. The big benefit of this mode of operations is that even if
none of the nodes are in range of a central access point, they can still talk to each other. This
is ideal for quickly transferring files between your laptop and a friend's when you are out of
range of an access point, for example. In addition, if one of the nodes in range happens to be
an Internet gateway, then traffic can be relayed to and from the Internet, just as if it were a
conventional access point. In Chapter 5, we'll see a method for using this mode to provide
gateway services without the need for expensive access point hardware. In Chapter 7, we'll
build on that simple gateway to create a public access wireless gatekeeper, with dynamic
firewalling, a captive web portal, user authentication, and real-time traffic shaping.
Page 12
Building Wireless Community Networks
You can use these modes of operation in conjunction with each other (and with other wired
networking techniques) to extend your network as you need it. It is very common, for
example, to use a long distance wireless link to provide access to a remote location, and then
set up an access point at that end to provide local access.
The total cost of your project is largely dependent on your project goals and how much work
you're willing to do yourself. While you can certainly spend tens of thousands of dollars on
outdoor, ISP-class equipment, you may find that you can save money (and get more
satisfaction) building similar functionality yourself, with cheaper off-the-shelf hardware.
If you simply want to connect your laptop to someone else's 802.11b network, you'll need
only a client card and driver software (at this point, compatible cards cost between $50 and
$200). Like most equipment, the price typically goes up with added features, such as an
external antenna connector, higher output power, a more sensitive radio, and the usual bells
and whistles. Once you select a card, find out what the network settings are for the network
you want to connect to, and hop on. If you need more range, a small omni-directional antenna
(typically $50-$100) can significantly extend the roaming range of your laptop.
If you want to provide wireless network access to other people, you'll need an access point
(AP). This has become something of a loaded term and can refer to anything from a low-end
"residential gateway" class box (about $200) to high-end, commercial quality, multi-radio
equipment ($1000+). They are typically small, standalone boxes that contain at least one radio
and another network connection (like Ethernet or a dialup modem). For the rest of this book,
we'll use the term access point to refer to any device capable of providing network access to
your wireless clients. As we'll see in Chapter 5, this can even be provided by a conventional
PC router equipped with a wireless card.
While a radio and an access point can make a simple short range network, you will more than
likely want to extend your coverage beyond what is possible out of the box. The most
effective way of extending range is to use external antennas. Antennas come in a huge
assortment of packages, from small omnidirectional tabletop antennas to large, mast-mounted
parabolic dishes. There isn't one "right" antenna for every application; you'll need to choose
the antenna that fits your needs (if you're trying to cover just a single building, you may not
even need external antennas). Take a look at Chapter 6 for specific antenna descriptions.
The most efficient wireless network consists of a single client talking to a single access point
a few feet away with absolutely clear line of sight between them and no other noise on the
channel being used (either from other networks or from equipment that shares the 2.4GHz
spectrum). Of course, with the possible exception of the home wireless LAN, these ideal
conditions simply aren't feasible. All of your users will need to "share the airwaves," and
more than likely they won't be able to see the access point from where they are located.
Fortunately, 802.11b gear is very tolerant of less than optimal conditions at close range. When
planning your network, be sure to look out for the following:
• Objects that absorb microwave signals, such as trees, earth, brick, plaster walls, and
people
Page 13
Building Wireless Community Networks
• Objects that reflect or diffuse signals, such as metal, fences, mylar, pipes, screens, and
bodies of water
• Sources of 2.4GHz noise, such as microwave ovens, cordless phones, wireless X-10
automation equipment, and other 802.11b networks
The more you can eliminate from the path between your access points and your clients, the
happier you'll be. You won't be able to get rid of all of the previous obstacles, but you should
be able to minimize their impact by working around them.
Rather than attempting to set up a single central access point with a high- gain
omnidirectional antenna, you will probably find it more effective to set up several low-range,
overlapping cells. If you use access point hardware, and all of the APs are connected to the
same physical network segment, users can even roam seamlessly between cells. Figure 2-1
shows an example of using multiple APs to cover a large area.
Figure 2-1. Using non-adjacent channels, several APs can cover a large area
As detailed in the specification, 802.11b breaks the available spectrum into 11 overlapping
channels, as shown in Table 2-1.
Page 14
Building Wireless Community Networks
6 2.437
7 2.442
8 2.447
9 2.452
10 2.457
11 2.462
The channels are spread spectrum and actually use 22MHz of signal bandwidth, so adjacent
radios will need to be separated by at least five channels to see zero overlap. For example,
channels 1, 6, and 11 have no overlap. Neither do 2 and 7, 3 and 8, 4 and 9, or 5 and 10.
While you will ideally want to use non-overlapping channels for your access points, in a
crowded setting (such as a city apartment building or office park) this is becoming less of an
option.
You stand a better chance at saturating your area with usable signals from many low-power
cells rather than a single tower with a high-gain antenna. As your individual cells won't need a
tremendous range to cover a wide area, you can use lower power (and lower cost) antennas,
further limiting the chances of interfering with other gear in the band. For example, you could
use as few as three channels (such as 1, 6, and 11) to cover an infinitely large area, with no
channel overlap whatsoever.
The worst possible case would involve two separate busy networks trying to occupy the same
channel, right next to each other. The further you can get away from this nightmare of
collisions, the better. Realistically, a single channel can easily support fifty or more
simultaneous users, and a fair amount of channel overlap is tolerable. The radios use the air
only when they actually have something to transmit, and they retransmit automatically on
error, so heavy congestion feels more or less like ordinary net lag to the end user. The
sporadic nature of most network traffic helps to share the air and avoid collisions, like playing
cards shuffling together into a pack.
You may have total control over your own access points, but what about your neighbors?
How can you tell what channels are in use in your local area?
While a spectrum analyzer (and an engineer to operate it) is the ultimate survey tool, such
things don't come cheap. Fortunately, you can get a lot of useful information using a good
quality client radio and software. Take a look at the tools that come with your wireless gear
(Lucent's Site Monitor tool, shown in Figure 2-2, which ships with Orinoco cards, is
particularly handy). You should be able to get an overview map of all networks in range and
which channels they're using.
Page 15
Building Wireless Community Networks
Figure 2-2. Lucent's Site Monitor tool shows you who's using 802.11b in your area
Other (non-802.11b) sources of 2.4GHz radio emissions show up as noise on your signal
strength meter. If you encounter a lot of noise on the channel you'd like to use, you can try to
minimize it by moving your access point, using a more directional antenna (see Chapter 6), or
simply picking a different channel. While you always want to maximize your received signal,
it is only usable if the ambient noise is low. The relationship of signal to noise is critical for
any kind of communications. It is frequently abbreviated as SNR, for signal to noise ratio. As
this number increases, so does the likelihood that you'll have reliable communications. (For
fine examples of low SNR, kindly consult your local Usenet feed.)
Of course, no known technology can determine the SNR of the actual data you're transmitting
or receiving. In the end, you still have to figure out for yourself how to pull signal from the
noise once it leaves the Application layer of your network.
To sum up: be a good neighbor, and think about what you're doing before turning on your
own gear. The radio spectrum is a public resource and, with a little bit of cooperation, can be
used by everyone to gain greater access to network resources.
As you roll out wireless equipment, you'll find yourself looking at your environment in a
different way. Air conditioning ducts, pipes, microwave ovens, power lines, and other sources
of nastiness start leaping into the foreground as you walk around. By the time you've set up a
couple of nodes, you will most likely be familiar with every source of noise or reflection in
the area you're trying to cover. But what if you want to extend your range, as in a several-mile
point-to-point link? Is there a better way to survey the outlying environment than walking the
entire route of your link? Maybe.
Topographical surveys have been made (and are constantly being revised) by the USGS in
every region of the United States. Topo (short for topographical) maps are available both on
paper and on CD-ROM from a variety of sources. If you want to know the lay of the land
between two points, the USGS topos are a good starting point.
The paper topo maps are a great resource for getting an overview of the surrounding terrain in
your local area. You can use a ruler to quickly gauge the approximate distance between two
points and to determine whether there are any obvious obstructions in the path. While they're
a great place to start assessing a long link, topographical maps don't provide some critical
information: namely, tree and building data. The land may appear to cooperate on paper, but
Page 16
Building Wireless Community Networks
if there's a forest or several tall buildings between your two points, there's not much hope for
a direct shot.
The USGS also provides DOQs (or Digital Orthophoto Quadrangles) of actual aerial
photography. Unfortunately, freely available versions of DOQs tend to be out of date
(frequently 8 to 10 years old), and recent DOQs are not only expensive but also often aren't
even available. If you absolutely must have the latest aerial photographs of your local area,
the USGS will let you download them for $30 per order and $7.50-$15 per file. You will
probably find it cheaper and easier to make an initial estimate with topo maps and then simply
go out and try the link.
You can buy paper maps from most camping supply stores or browse them online for free at
http://www.topozone.com/. If you're interested in DOQs, go to the USGS directly at
http://earthexplorer.usgs.gov/. We'll take a look at some nifty things you can do with topo
maps on CDRom and your GPS in Chapter 6.
Presumably, no matter how many wireless clients you intend to support, you will eventually
need to "hit the wire" in order to access other networks (such as the Internet). How do packets
find their way from the unbridled freedom of the airwaves to the established, hyper-
interconnected labyrinth of the Internet? This chapter describes what you need to know to do
that.
As with any network supporting different physical mediums, network bridges must exist that
are capable of exchanging data between the various network types. A wireless gateway
consists of a radio card and a network card (usually Ethernet). In the case of 802.11b, radios
participating in the wireless network must operate in one of two modes: BSS or IBSS .
BSS stands for Basic Service Set. In this operating mode, a piece of hardware called an access
point (AP) provides wireless-to-Ethernet bridging. Before gaining access to the wired
network, wireless clients must first establish communications with an access point within
range. Once the AP has authenticated the wireless client, it allows packets to flow between
the client and the attached wired network, effectively acting as a true Layer 2 bridge, as
Page 17
Building Wireless Community Networks
shown in Figure 3-1. A related term, ESS (or Extended Service Set), refers to a physical
subnet that contains more than one AP. In this sort of arrangement, the APs can communicate
with each other to allow authenticated clients to "roam" between them, handing off IP
information as the clients move about. Note that (as of this writing) there are no APs that
allow roaming across networks separated by a router.
Figure 3-1. In BSS (or ESS) mode, clients must authenticate to a hardware access point before
being able to access the wired network
IBSS stands for Independent Basic Service Set and is frequently referred to as ad-hoc or peer-
to-peer mode. In this mode, no hardware access point is required. Any network node that is
within range of any other can commence communications if they agree on a few basic
parameters. If one of those peers also has a wired connection to another network, it can
provide access to that network. Figure 3-2 shows a model of an IBSS network.
Figure 3-2. In IBSS mode, nodes can talk to any other node in range. A node with another
network connection can provide gateway services
Note that an 802.11b radio must be set to work in either of these modes but cannot work in
both simultaneously. Both modes support shared-key WEP encryption (more on that later).
Page 18
Building Wireless Community Networks
Access points are widely considered ideal for campus coverage. They provide a single point
of entry that can be configured by a central authority. They typically allow for one or two
radios per AP, theoretically supporting hundreds of simultaneous wireless users at a time.
They must be configured with an ESSID (Extended Service Set ID, also known as the
Network Name or WLAN Service Area ID, depending on who you talk to); it's a simple string
that identifies the wireless network. Many use a client program for configuration and a simple
password to protect their network settings.
• MAC address filtering. A client radio attempting access must have its MAC address
listed on an internal table before being permitted to associate with the AP.
• Closed networks. Usually, a client can specify an ESSID of "ANY" to associate with
any available network. In a closed network, the client must specify the ESSID
explicitly, or it can't associate with the AP.
• External antennas.
• Continual link-quality monitoring.
• Extended logging, statistics, and performance reporting.
Other enhanced modes include dynamic WEP key management, public encryption key
exchange, channel bonding, and other fun toys. Unfortunately, these extended modes are
entirely manufacturer- (and model-) specific, are not covered by any established standard, and
do not interoperate with other manufacturer's equipment. It should also be noted that, once a
client has associated itself with an AP, there are no further restrictions imposed by the AP on
what services the client can access.
APs are an ideal choice for private networks with many wireless clients that exist in a
confined physical space, especially on the same physical subnet (like a business or college
campus). They provide a high degree of control over who can access the wire, but they are not
cheap (the average AP at this writing costs between $800 and $1000).
Another class of access point is occasionally referred to as a residential gateway. The Apple
AirPort, Orinoco RG-1000, and Linksys WAP11 are popular examples of low-end APs. They
are typically much less expensive than their commercial counterparts, costing between $200
and $500. Many have built-in modems, allowing for wireless-to-dialup access (which can be
very handy, if Ethernet access isn't available wherever you happen to be). Most even provide
Network Address Translation (NAT), DHCP, and bridging services for wireless clients. While
they may not support as many simultaneous clients as a high-end AP, they can provide cheap,
simple access for many applications. By configuring an inexpensive AP for bridged Ethernet
mode, you can have a high degree of control over what individual clients can access on the
wired network (see Section 7.6 in Chapter 7).
Despite their high cost, APs have their place in building community wireless networks. They
are especially well suited to remote repeater locations, due to their ease of configuration, low
power consumption (compared to a desktop or laptop PC), and lack of moving parts. We'll go
into detail on how to set up an AP in Chapter 4.
Page 19
Building Wireless Community Networks
If the goal of your wireless project is to provide public access to network services, the
functionality high-end APs provide will almost certainly be overkill, particularly in light of
their high cost. Luckily, with IBSS mode, AP hardware is entirely optional.
Radios that are operating in IBSS mode can communicate with each other if they have the
same ESSID and WEP settings. As stated earlier, a computer with an 802.11b card and
another network connection (usually Ethernet or dialup) can serve as a gateway between the
two networks. Add in DHCP and NAT services, and you effectively have a full-blown
Internet gateway. As various free operating systems can provide these services and will run
well on hardware that many people already have lying around in closets (e.g., 486 laptops and
low-end Pentium systems), this mode of operation is an increasingly popular alternative to
expensive APs. If you have host hardware available already, the low cost of making a
gateway is very attractive (the cost of the average client radio card is $120, or about half that
of a low-end AP).
What is missing from a do-it-yourself gateway? Instead of the myriad access control methods
that actual APs provide, the only out-of-the-box access control you have available is WEP. As
we saw earlier, a shared key does little on its own for security, and it isn't appropriate in a
public network setting anyway. So how can we provide network access and still discourage
abuse by anonymous wireless clients? See Chapter 5 and Chapter 7.
In Chapter 5, we'll build a Linux-based wireless gateway from scratch. In Chapter 7, we'll
examine one method of extending the gateway to provide different classes of service,
depending on who connects to it.
3.2.1 DHCP
The days of static IP addresses and user-specified network parameters are thankfully far
behind us. Using DHCP (Dynamic Host Configuration Protocol), it is possible (and even
trivial) to set up a server that responds to client requests for network information. Typically, a
DHCP server provides all the information that a client needs to begin routing packets on the
network, including the client's own IP address, the default Internet gateway, and the IP
addresses of the local DNS servers. The client configuration is ridiculously easy and is, in
fact, configured out of the box for DHCP in all modern operating systems.
While a thorough dissection of DHCP is beyond the scope of this book, a brief overview is
useful. A typical DHCP session begins when a client boots up, knowing nothing about the
network it is attached to except its own hardware MAC address. It broadcasts a packet saying,
effectively, "I am here, and this is my MAC address. What is my IP address?" A DHCP server
on the same network segment listens for these requests and responds: "Hello MAC address.
Page 20
Building Wireless Community Networks
Here is your IP address, and by the way, here is the IP address to route outgoing packets to,
and some DNS servers are over there. Come back in a little while and I'll give you more
information." And the client, now armed with a little bit of knowledge, goes about its merry
way. This model is shown in Figure 3-3.
Figure 3-3. DHCP lets a node get its network settings dynamically and easily
In a wireless environment, DHCP is an absolute necessity. There isn't much point in being
able to wander around without a cable if you need to manually set the network parameters for
whatever network you happen to be in range of. It's much more convenient to let the
computers work it out on their own (and let you get back to more important things, like IRC
or "Quake III Arena"). Since DHCP lets a node discover information about its network, one
can get "online" without any prior knowledge about that particular network's layout. This
service demonstrates a condition that network administrators have known for years: users just
want to get online without knowing (or even caring) about the underlying network. From their
perspective, it should just work. DHCP makes this kind of magic possible.
From a network admin's perspective, the magic isn't even terribly difficult to bring about. As
long as you have exactly one DHCP server running on your network segment, your clients
can all pull from a pool of available IP addresses. The DHCP server manages the pool on its
own, reclaiming addresses that are no longer in use and reassigning them to new clients.
In many cases, a wired network's existing DHCP server serves wireless users with no trouble.
It sees the wireless node's DHCP request just as it would any other and responds accordingly.
If your wired network isn't already providing DHCP, or if your wireless gateway isn't capable
of L2 bridging, don't worry. We'll cover setting up the ISC's dhcpd server in Linux in Chapter
5.
3.2.2 DNS
My, how different the online world would be if we talked about sending mail to
[email protected] or got excited about having just been 64.28.67.150'd. DNS is the
dynamic telephone directory of the Internet, mapping human friendly names (like
oreillynet.com or slashdot.org) to computer friendly numbers (like the dotted quads above).
The Internet without DNS is about as much fun and convenient as referring to people by their
Social Security numbers.
Much like DHCP, your network's existing DNS servers should be more than adequate to
provide name resolution services to your wireless clients. However, depending on your
particular wireless application, you may want to get creative with providing additional DNS
services. A caching DNS server might be appropriate, to reduce the load on your primary
Page 21
Building Wireless Community Networks
DNS servers (especially if you have a large number of wireless clients). You might even want
to run separate DNS for your wireless hosts, so that wireless nodes can easily provide services
for each other.
3.2.3 NAT
In order for any machine to be reachable via the Internet, it must be possible to route traffic to
it. A central authority, the IANA (Internet Assigned Numbers Authority,
http://www.iana.org/), holds the keys to the Internet. This international body controls how IP
addresses are parceled out to the various parts of the world, in an effort to keep every part of
the Internet (theoretically) reachable from every other and to prevent the accidental reuse of
IP addresses in different parts of the world. Unfortunately, due to the unexpectedly
tremendous popularity of the Net, what was thought to be plenty of address space at design
time has proven to be woefully inadequate in the real world. With thousands of new users
coming online for the first time every day, the general consensus is that there simply aren't
enough IP addresses to go around anymore. Most ISPs are increasingly paranoid about the
shortage of homesteading space, and they are loath to give out more than one per customer
(and, in many cases, they won't even do that anymore, thanks to the wonders of DHCP).
Now we see the inevitable problem: suppose you have a single IP address allocated to you by
your ISP, but you want to allow Internet access to a bunch of machines, including your
wireless nodes. You certainly don't want to pay exorbitant fees for more address space just to
let your nephew get online when he brings his wireless laptop over once a month.
This is where NAT can help you. Truly a mixed blessing, NAT (referred to in some circles as
"masquerading") provides a two-way forwarding service between the Internet and another
network of computers. A computer providing NAT typically has two network interfaces. One
interface is connected to the Internet (where it uses a real live IP address), and the other is
attached to an internal network. Machines on the internal network use any of IANA's
thoughtfully assigned, reserved IP addresses and route all of their outgoing traffic through the
NAT box. When the NAT box receives a packet bound for the Internet, it makes a note of
where the packet came from. It then rewrites the packet using its "real" IP address and sends
the modified packet out to your ISP (where it winds its way through the rest of the Internet,
hopefully arriving at the requested destination). When the response (if any) comes back, the
NAT box looks up who made the original request, rewrites the inbound packet, and returns it
to the original sender. As far as the rest of the Net is concerned, only the NAT machine is
visible. And as far as the internal clients can tell, they're directly connected to the Internet.
Figure 3-4 shows a model of a NAT configuration.
Page 22
Building Wireless Community Networks
Figure 3-4. Using NAT, several computers can share a single "real" IP address
The IANA has reserved the following sets of IP addresses for private use (as outlined in RFC
1918, http://rfc.net/rfc1918.html):
10.0.0.0 - 10.255.255.255
172.16.0.0 - 172.31.255.255
192.168.0.0 - 192.168.255.255
These are addresses that are guaranteed never to be used on the Internet. As long as your
internal machines use IP addresses in any of these three ranges, your traffic will not interfere
with any other host on the Net. As an added bonus, since the reserved IP address traffic isn't
even routed over the Internet, you effectively get a free firewall for all of your NAT'd hosts.
NAT is handy but isn't without its drawbacks. For example, some services may not work
properly with some implementations of NAT. Most notably, active FTP sessions fail on some
NAT boxes. Another big disadvantage to NAT is that it effectively makes the Internet a read-
only medium, much like television. If you can have only outbound traffic (to web servers, for
example) and traffic from the Internet can't reach your machine directly, then you have no
way of serving data and contributing back to the Net! This doesn't prevent you from using
two-way services like IRC and email, but it does preclude you from easily running services
where Internet users connect to you directly (for example, running your own web server from
behind a NAT isn't trivial).
Despite these drawbacks, NAT is an invaluable tool for allowing throngs of people to access
Internet resources. In Chapter 5, we'll build a Linux gateway that will do NAT for you and
handle almost every popular form of Internet traffic you care to throw at it (including active
FTP).
Of course, if you're lucky enough to have a ton of live IP address space, feel free to flaunt it
and assign live IPs to your wireless clients! Naturally, most people (and, indeed, their laptops)
are unprepared for the unbridled adrenaline rush of using a live IP address without a firewall.
Page 23
Building Wireless Community Networks
But if you have that many real IPs to throw around, you must be used to living large. Just
don't worry when you find your clients spontaneously rebooting or suddenly serving 0-dAy
W@r3z. It's all part of the beautiful online experience.
Although the differences between tethered and untethered are few, they are significant. For
example, everyone has heard of the archetypal "black-hat packet sniffer," a giggling sociopath
sitting on your physical Ethernet segment, surreptitiously logging packets for his own
nefarious ends. This could be a disgruntled worker, a consultant with a bad attitude, or even
(in one legendary case) a competitor with a laptop, time on his hands, and a lot of nerve.[1]
Although switched networks, a reasonable working environment, and conscientious reception
staff can go a long way to minimize exposure to the physical wiretapper, the stakes are raised
with wireless. Suddenly, one no longer needs physical presence to log data: why bother trying
to smuggle equipment onsite when you can crack from your own home or office two blocks
away with a high-gain antenna?
As the story goes, a major computer hardware manufacturer once found a new "employee" sitting in a previously unoccupied
cube. He had evidently been there for three weeks, plugged into the corporate network and happily logging data before HR got
around to asking who he was.
Visions of cigarette smoking, pale skinned über-crackers in darkened rooms aside, there is a
point that many admins tend to overlook when designing networks: the whole reason that the
network exists is to connect people to each other! Services that are difficult for people to use
will simply go unused. You may very well have the most cryptographically sound method on
the planet for authenticating a user to the system. You may even have the latest in biometric
identification, full winnow and chaff capability, and independently verified and digitally
signed content assurance for every individual packet. But if the average user can't simply
check her email, it's all for naught. If the road to hell is paved with good intentions, the
customs checkpoint must certainly be run by the Overzealous Security Consultant.
The two primary concerns when dealing with wireless clients are these:
As it turns out, with a little planning, these problems can be addressed (or neatly sidestepped)
in most real-world cases. In this section, we'll look at ways of designing a network that keeps
your data flowing to where it belongs, as quickly and efficiently as possible.
Let's take a look at the tools we have available to put controls on who can access what.
3.3.1 WEP
The 802.11b specification outlines a form of encryption called wired equivalency privacy, or
WEP. By encrypting packets at the MAC layer, only clients who know the "secret key" can
associate with an access point or peer-to- peer group. Anyone without the key may be able to
see network traffic, but every packet is encrypted.
Page 24
Building Wireless Community Networks
The specification employs a 40-bit, shared-key RC4 PRNG[2] algorithm from RSA Data
Security. Most cards that talk 802.11b (Agere Orinoco, Cisco Aironet, and Linksys WPC11,
to name a few) support this encryption standard.
Pseudo-Random Number Generator. It could be worse, but entropy takes time.
Although hardware encryption sounds like a good idea, the implementation in 802.11b is far
from perfect. First of all, the encryption happens at the link layer, not at the application layer.
This means your communications are protected up to the gateway, but no further. Once it hits
the wire, your packets are sent in the clear. Worse than that, every other legitimate wireless
client who has the key can read your packets with impunity, since the key is shared across all
clients. You can try it yourself; simply run tcpdump on your laptop and watch your neighbor's
packets just fly by, even with WEP enabled.
Some manufacturers (e.g., Agere and Cisco) have implemented their own proprietary
extensions to WEP, including 128-bit keys and dynamic key management. Unfortunately,
because they are not defined by the 802.11b standard, there is no guarantee that cards from
different manufacturers that use these extensions will interoperate (and, generally speaking,
they don't).
To throw more kerosene on the burning WEP tire mound, a team of cryptographers at the
University of California at Berkeley have identified weaknesses in the way WEP is
implemented, effectively making the strength of encryption irrelevant. With all of these
problems, why is WEP still supported by manufacturers? And what good is it for building
public access networks?
WEP was not designed to be the ultimate "killer" security tool (nor can anything seriously
claim to be). Its acronym makes the intention clear: wired equivalency privacy. In other
words, the aim behind WEP was to provide no greater protection than you would have when
you physically plug into your Ethernet network. (Keep in mind that in a wired Ethernet
setting, there is no encryption provided by the protocol at all. That is what application layer
security is for; see the tunneling discussion later in this chapter.)
As we'll see in Chapter 7, one area where WEP is particularly useful is at either end of a long
point-to-point backbone link. In this application, unwanted clients could potentially degrade
network performance for a large group of people, and WEP can help not only discourage
would-be link thieves, but also encourage them to set up more public access gateways.
The primary security consideration for wireless network access is where to fit it into your
existing network. Regardless of your gateway method (AP or DIY) you need to consider what
services you want your wireless users to be able to access. Since the primary goal of this book
is to describe methods for providing public access to network services (including access to the
Internet), I strongly recommend setting up your wireless gateways in the same place you
Page 25
Building Wireless Community Networks
would any public resource: in your network's DMZ or outside your firewall altogether. That
way, even in a complete breakdown of security precautions, the worst that any social deviant
will end up with is Internet access, and not unrestricted access to your private internal
network.
This configuration, as shown in Figure 3-5, leaves virtually no incentive for anyone to try to
compromise your gateway, as the only thing to be gained would be greater Internet access.
Attacks coming from the wireless interface can easily log MAC address and signal strength
information. In IBSS mode, this is an even greater deterrent. As the would-be attacker needs
to transmit to carry out an attack, they give away not only a unique identifier (their MAC
address), but also their physical location!
Figure 3-5. Place your wireless gateways outside of your private network!
Assuming that all wireless connectivity takes place outside of your private network, what
happens when you or your friends want to connect from the wireless back to the inside
network? Won't other wireless users be able to just monitor your traffic and grab passwords
and other sensitive information? Section 3.3.3 addresses this potential problem.
Application layer encryption is a critical technology when dealing with untrusted networks
(like public-access wireless links, for example). When using an encrypting tunnel, you can
secure your communications from eavesdroppers all the way to the other end of the tunnel.
If you're using a tunnel from your laptop to another server, would-be black hats listening to
your conversation will have the insurmountable task of cracking strong cryptography. Until
someone finds a cheap way to build a quantum computer (and perhaps a cold fusion cell to
power it), this activity is generally considered a waste of time. In Figure 3-6, a web server
providing 128-bit SSL connections provides plenty of protection, all the way to your wireless
laptop. SSL provides application layer encryption.
Page 26
Building Wireless Community Networks
Figure 3-6. WEP only encrypts to the gateway, exposing your traffic to other wireless users and
anything after the wire. Tunnels protect your traffic from end to end
SSL is great for securing web traffic, but what about other network services? Take this typical
scenario: You're at work or at home, merrily typing away on your wireless laptop. You want
to retrieve your email from a mail server with a POP client (Netscape Mail, Eudora,
fetchmail, etc.). If you connect to the machine directly, your email client sends your login and
password "in the clear." This means that a nefarious individual somewhere between you and
your mail server (either elsewhere on your wireless network, or even "on the wire" if you are
separated by another network) could be listening and could grab a copy of your information
en route. This login could then not only be used to gain unauthorized access to your email, but
in many cases also to grant a shell account on your mail server!
To prevent this, you can use the tunneling capabilities of SSH. An SSH tunnel works like this:
rather than connecting to the mail server directly, we first establish an SSH connection to the
internal network that the mail server lives in (in this case, the wireless gateway). Your SSH
client software sets up a port-forwarding mechanism, so that traffic that goes to your laptop's
POP port magically gets forwarded over the encrypted tunnel and ends up at the mail server's
POP port. You then point your email client to your local POP port, and it thinks it is talking to
the remote end (only this time, the entire session is encrypted). Figure 3-7 shows a model of
an SSH tunnel in a wireless network.
Page 27
Building Wireless Community Networks
Figure 3-7. With an SSH tunnel in place, your otherwise insecure conversation stays private
With the tunnel in place, anyone who tries to monitor the conversation between your laptop
and the mail server gets something resembling line noise. It's a good idea to get in the habit of
tunneling anything that you want to keep private, even over wired networks. SSH tunneling
doesn't have to stop at POP connections either. Any TCP port (SMTP, for example) can easily
be set up to tunnel to another machine running SSH, almost anywhere on the Internet. We'll
see an example of how to do that in Chapter 7. For a full discussion of the ins and outs of this
very flexible (and freely available) tool, I highly recommend O'Reilly's SSH: The Definitive
Guide, by Daniel J. Barrett and Richard E. Silverman.
3.4 Summary
In order to maintain maximum compatibility with available 802.11b client hardware and yet
still provide responsible access to the Internet, we can apply a combination of inexpensive
hardware and freely available software to strike an acceptable balance between access and
security.
In the following chapters, we'll see how to set up basic wireless access to your existing wired
network. We will then build a workable method for providing wireless services to your local
community, for minimal cost, while promoting community participation and individual
responsibility.
Page 28
Building Wireless Community Networks
The access point hardware controls access to and from both networks. On the wireless side,
most vendors have implemented 802.11b access control methods (like WEP encryption keys,
"closed" network ESSIDs, and MAC address filtering). Some have added proprietary
extensions to provide additional security, like public key encryption.[1] Many access points
also allow control over what the wired network can send to the wireless clients, through
simple firewall rules.
Unfortunately, as is usually the case with proprietary extensions, these services can be used only if all of your network clients
are using hardware from the same vendor.
In addition to providing access control, the access point also maintains its own network
connections. This includes functions like dialing the phone and connecting to an ISP on
demand, or using DHCP on the Ethernet interface to get a network lease. Most access points
can provide NAT and DHCP service to the wireless clients, thereby supporting multiple
wireless users while only requiring a single IP address from the wire. Some support direct
bridging, allowing the wired and wireless networks to exchange data as if they were
physically connected together. If the access point has multiple radios, it can bridge them
together with the wire, allowing for a very flexible, extendable network.
Another important service provided by APs is the ability to "hand off" clients as they wander
between access points. This lets users walk around a college campus, for example, without
ever dropping their network connection. Current AP technology only allows roaming between
access points on the same physical subnet (that is, APs that aren't separated by a router).
Unfortunately, the roaming protocol was left unimplemented in the 802.11 spec, so each
manufacturer has implemented their own method. This means that hand-offs between access
points of different manufacturers aren't currently possible.
In the last year, at least 20 different access point hardware solutions have hit the consumer
market. Low cost models (intended for home or small office use) like the Linksys WAP11
and D-Link DWL-1000AP currently retail for around $200. Higher-end APs like the Orinoco
AP-1000 and Cisco Aironet 350 cost over $1000. Typically, higher-priced equipment
includes more features, greater range, and generally more stable operations. While every AP
will claim 802.11b (or Wi-Fi[2] ) compliance, they are not all alike. Features that set different
models apart include:
Wi-Fiis the "marketing friendly" name picked by the WECA (the Wireless Ethernet Compatibility Alliance) to refer to
802.11b-compliant gear. See http://www.weca.net/ if you're so inclined.
In general, look for an AP in your price range that works for your intended application, with
the greatest possible range. Single radio APs can support several users simultaneously, and, as
we'll see in Chapter 6, adding APs to your network is probably preferable to adding higher-
gain antennas or amps to your existing AP.
Page 29
Building Wireless Community Networks
One feature that is in high demand (among users trying to go for distance) is the ability to
bridge over the air to another access point. Allegedly, the Intel 2011 can do AP-to-AP
bridging (as can the Linksys WAP11 after a firmware upgrade). But reports from the field
seem to indicate shaky performance at best, as of this writing. Normally, APs don't talk to
each other over the air; they're designed to talk to client cards. So on a long distance point-to-
point link, you'll need to either use a client PC router to talk to an AP or use two routers in
IBSS mode (with no AP). See the information in Section 7.1 in Chapter 7 if you're interested
in long-distance point-to-point links. By the time this book makes it to press, the
manufacturers should have their firmware in better shape (we hope).
You should also seriously consider how to fit APs into your existing wired network. Even
with WEP encryption and other access control methods in effect, AP security is far from
perfect. Because an access point is, by definition, within range of all wireless users, every
user associated with your access point can see the traffic of every other user. Unless otherwise
protected with application layer encryption, all email, web traffic, and other data is easily
readable by anyone running protocol analysis tools such as tcpdump or ethereal. As we saw in
Chapter 3, relying on WEP alone to keep people out of your network may not be enough
protection against a determined black hat.
Wireless access points that are on the consumer market today were designed to connect a
small group of trusted people to a wired network and lock out everyone else. The access
control methods implemented in the APs reflect this philosophy, and if that is how you intend
to use the gear, it should work very well for you. For example, suppose you want to share
wireless network access with your neighbor but not with the rest of the block. You could
decide on a mutual private WEP key and private ESSID and keep them a secret between you.
Because you presumably trust your neighbor, this arrangement could work for both of you.
You could even make a list of all of the radios that you intend to use on the network and limit
the access point to only allow them to associate. This would require more administrative
overhead, as one of you would have to make changes to the AP each time you wanted to add
another device, but it would further limit who could access your wireless network.
While a shared secret WEP key and static table of hardware MAC addresses may be practical
for a home or small office, these access control methods don't make sense in a public access
setting. If you intend to offer network services to your local area, this "all or nothing" access
control method is unusable. As we'll see in Chapter 7, it may be more practical to let
everyone associate with your access point and use other methods for identifying users and
granting further access. These services take place beyond the AP itself, namely, at a router
that the AP is directly connected to (see the captive portal discussion in Chapter 7). Such an
arrangement requires a bit more equipment and effort to get started, but it can support
hundreds of people across any number of cooperative wireless nodes with very little
administrative overhead.
Page 30
Building Wireless Community Networks
Before we get too fancy, we have to understand how to configure an access point. Let's take a
look at how to set up a very popular access point, the Apple AirPort.
The Mac AirPort is a tremendously popular access point. It looks like a slick, retro-futuristic
prop from "War of the Worlds," and it is very portable and rugged. While designed for use
with the Mac platform, it works very well as a general purpose access point (and you don't
even need a Mac to configure it; see the next section). As I write this, the AirPort sells retail
for about $299. What does that get you?
What doesn't it get you? It has only one radio (actually, an embedded Orinoco Silver card)
and no external antenna connector. But this isn't much of a problem, because the internal
Silver card itself has an external connector. See
http://homepage.mac.com/hotapplepi/airport/or
http://www.wwc.edu/~frohro/Airport/Airport.html for examples of how to add your own
antenna.
Out of the box, the AirPort will try to get a DHCP lease from the Ethernet and start serving
NAT and DHCP on the wireless with no password. Yes, by simply plugging your new toy
into your LAN, you have eliminated all of the hard work that went into setting up your
firewall. Anyone within earshot now has unrestricted wireless access to the network you
plugged it into!
While this could be handy as a default configuration (say, at a conference or other public
access network), this probably isn't what you want. To change the defaults, you'll need
configuration software.
If you have a Mac handy, you are in luck. The AirPort Admin utility that ships with the
AirPort is excellent (although only for Mac OS 9 or later). Apple has gone out of their way to
make the whole AirPort system easy to set up, even for beginners. If you don't own a Mac,
you have a couple of options. It turns out that the innards of the AirPort are virtually identical
to the Orinoco RG-1000 (previously, the Lucent Residential Gateway). That means that the
RG configuration utility for Linux (called cliproxy) also works with the AirPort. You can get
a copy of Lucent's cliproxy utility at http://www.wavelan.com/.
Jon Sevy has done extensive work with the AirPort and has released an open source Java
client that configures the AirPort and the RG-1000. You can get a copy from
http://edge.mcs.drexel.edu/GICL/people/sevy/airport/. He has also compiled a tremendous
amount of information on the inner workings of the AirPort and has a lot of resources online
Page 31
Building Wireless Community Networks
at this site. Since his utility is open source and cross-platform (and works very well), we'll use
it in the following examples.
To use the Java Configurator app, you'll need a copy of the Java Runtime Environment.
Download it from http://java.sun.com/, if you don't already have it. You can start the utility
by running the following in Linux:
The AirPort can be configured over the Ethernet port or over the wireless. When the
application window opens, you can click the Discover Devices button to auto-locate all of the
APs on your network. When you find the IP address of the AP you want to configure, type it
into the Device address field, and type the password into the Community name field. If you're
unsure about the IP address or the password, the AirPort ships with a default password of
public and an IP address of 10.0.1.1 on the wireless interface (it picks up the wired IP address
via DHCP; use Discover Devices to find it if you're configuring it over the Ethernet). Once
you've entered the correct information, click the Retrieve Settings button.
The very first thing you should change is the Community name on the first panel. Otherwise,
anyone can reconfigure your AirPort by using the public default! While you're there, you can
set the name of the AirPort (which shows up in network scans) and also the location and
contact information, if you like. These fields are entirely optional and have no effect on
operations.
You should also choose a Network name, under the Wireless LAN Settings tab. This is also
known as the ESSID, and it will identify your network to clients in range. If you're running a
"closed" network, it needs to be known ahead of time by any host attempting to connect, as
described in the next section.
Page 32
Building Wireless Community Networks
As stated earlier, the default AirPort configuration enables LAN access by default. If you're
using DSL or a cable modem, or if you are installing the AirPort on an existing Ethernet
network, this is what you want to use. In the Java Configurator, take a look at the Network
Connection tab and check the Connect to network through Ethernet port radio button.
From here, you can configure the IP address of the AirPort via DHCP, by entering the IP
information manually, or by using PPPoE. You'll probably want to use DHCP, unless your
ISP requires a manual IP address or PPPoE.
There is also a radio button on the Network Connection tab marked Connect to network
through modem. Use this option if your only network connection is via dialup. Yes, it's very
slow, but at least you're wireless. Note that the dialup and Ethernet choices are exclusive and
can't be used at the same time.
When you check Connect to network through modem, the pane prompts you for phone
number, modem init string, and other dialup-related fields. Make sure that Automatic dialing
is checked, so it dials the phone when you start using the AirPort. Click on the
Username/Password/Login Script button to enter your login information. On this screen, you
can also define a custom login script, if you need to. The default script has worked fine for me
with a couple of different ISPs.
Once the AirPort is configured for dialup, it will dial the phone and connect any time it senses
Internet traffic on the wireless port. Just start using your wireless card as usual, and, after an
initial delay (while it's dialing the phone), you're online.
By default, the AirPort acts as both a NAT server and a DHCP server for your wireless
clients.[3] DHCP service is controlled by the DHCP Functions tab. To turn DHCP on, check
the Provide DHCP address delivery to wireless hosts box. You can specify the range of IPs to
issue; by default the AirPort hands out leases between 10.0.1.2 and 10.0.1.50. You can also
set a lease time here. The lease time specifies the lifetime (in seconds) of an issued IP address.
After this time expires, the client reconnects to the DHCP server and requests another lease.
The default of 0 (or unlimited) is probably fine for most installations, but you may want to set
it shorter if you have a large number of clients trying to connect to your AirPort.
If you're just joining us, NAT and DHCP stand for Network Address Translation and Dynamic Host Configuration Protocol,
respectively. See Chapter 3 for more details.
If you don't have another DHCP server on your network, the AirPort can provide service for
your wired hosts as well. Check the Distribute addresses on Ethernet port, too box if you
want this functionality.
Only check this box if you don't have another DHCP server on your
network! More than one DHCP server on the same subnet is a bad thing
and will bring the wrath of the sysadmin down upon you. Watching two
DHCP d k h l b f i
Page 33
Building Wireless Community Networks
DHCP servers duke out who gets to serve leases may be fun in your
spare time, but it can take down an entire network and leave you
wondering where your job went. What were you doing connecting
unauthorized gear to the company network, anyway?
If you have more than one AirPort on the same wired network, make sure that you enable
DHCP to the wire on only one of them and, again, only if you don't already have a DHCP
server.
NAT is very handy if you don't have many IP addresses to spare (and these days, few people
do). It also gives your wireless clients some protection from the wired network, as it acts as an
effective one-way firewall (see Chapter 3 for the full story of NAT and DHCP). In the
Configurator, NAT is set up in the Bridging Functions tab. To enable NAT, click the Provide
network address translation (NAT) radio button. You can either specify your own private
address and netmask or leave the default (10.0.1.1 / 255.255.255.0).
4.2.5 Bridging
A big disadvantage to running NAT on your wireless hosts is that they become less accessible
to your wired hosts. While the wireless users can make connections to any machine on the
wire, connecting back through a NAT is difficult (the AirPort provides some basic support for
this by allowing for static port mappings, but this is far from convenient). For example, if you
are running a Windows client on the wireless, the Network Neighborhood will show other
wireless clients only and not any machines on the wire, since NAT effectively hides broadcast
traffic (which the Windows SMB protocol relies on). If you already have a DHCP server on
your wired network and are running private addresses, the NAT and DHCP functions of the
AirPort are redundant and can simply get in the way.
Rather than duplicate effort and make life difficult, you can disable NAT and DHCP and
enable bridging to the wire. Turn off DHCP under DHCP Functions (as we saw earlier), and
check the Act as transparent bridge (no NAT) under the Bridging Functions tab. When the
AirPort is operating in this mode, all traffic destined for your wireless clients that happens on
the wire gets broadcast over wireless, and vice versa. This includes broadcast traffic (such as
DHCP requests and SMB announcement traffic). Apart from wireless authentication, this
makes your AirPort seem completely invisible to the rest of your network.
Once bridging is enabled, you may find it difficult to get the unit back into NAT mode. If it
seems unresponsive to the Java Configurator (or Mac AirPort admin utility) while in bridging
mode, there are a couple of ways to bring it back.
If you have a Mac, you can do a manual reset. Push the tiny button on the bottom of the
AirPort with a paper clip for about two seconds. The green center light on top will change to
amber. Connect the Ethernet port on your AirPort to your Mac and run the admin utility. The
software should let you restore the AirPort to the default settings. You have five minutes to do
this before the amber light turns green and reverts to bridged mode.
If you're running Linux, you can easily bring the AirPort back online using Lucent's cliproxy
utility, without needing a hard reset. Run the following commands from a Linux machine
(either on the wire or associated over the wireless):
Page 34
Building Wireless Community Networks
$ cliproxy
[ORiNOCO]> show accesspoints
Searching...
NoCat(config)> done
NoCat> exit
Of course, substitute your password for publicand your IP address for the previous sample.
At this point, the AirPort should reboot with NAT and DHCP enabled and bridging turned
off.
If you're running Windows and need to reset an AirPort in bridged mode, I suggest you make
friends with a Mac or Linux user. You might be able to get things back to normal by doing a
hard reset (holding down the reset button with a paper clip for 30 seconds while powering the
unit up), but I've never been able to make that work. The previous two methods—using a Mac
hard reset or the Linux cliproxy utility—have worked well for me in the past. I keep a copy of
cliproxy handy for just this reason.
If you really want to lock down your network at the access point, you have the following tools
at your disposal: WEP encryption, filtering on MAC address (the radio card's serial number),
and running a closed network. The three services are completely separate, so you don't
necessarily have to run MAC filtering anda closed network, for example. Combining all these
features may not make your network completely safe from a determined miscreant, but it will
discourage the vast majority of would-be network hijackers.
To set the WEP keys, click the Wireless LAN Settings tab and enter the keys in the fields
provided. Also check Use encryption and uncheck Allow unencrypted data to require WEP on
your network. Give a copy of this key to each of your wireless clients.
With MAC filtering enabled, the AirPort keeps an internal table of MAC addresses that are
permitted to use the AirPort. Click the Access Control tab and enter as many MAC addresses
as you like. Only radios using one of the MACs listed here will be allowed to associate with
the AirPort. The MAC address of a radio card should be printed on the back of it (a MAC
address consists of six hex numbers of the form 12:34:56:ab:cd:ef).
Page 35
Building Wireless Community Networks
A closed network makes the AirPort refuse connections from radios that don't explicitly set
the ESSID, i.e., clients with a blank ESSID or one set to ANY. To make your network closed,
check the Closed network box under Wireless LAN Settings.
Remember that without encryption, all traffic is sent in the clear, so anyone within range
could potentially read and reuse sensitive information (such as ESSIDs and valid MAC
addresses). Even with WEP, every other legitimate user can see this traffic. If you need to
restrict access to a user later, you'll need to change the WEP key on every wireless client. But
for small groups of trusted users, using these access control methods should discourage all but
the most determined black hat without too much hassle.
4.2.7 Roaming
Wireless roaming can be very handy if your network is arranged in a way that you can
support it. In order for roaming to be possible, all your APs need to be from the same
manufacturer, reside on the same physical wired subnet (i.e., on the same IP network, with no
intervening routers), and have the same Network name (ESSID).
In the AirPort, roaming is automatically enabled if all of these are true. Make sure that all of
your AirPorts have the exact same Network name under Wireless LAN Settings. If for some
reason you want to disable roaming, just give each AirPort a different ESSID.
In the 802.11b specification (in the United States), the 2.4GHz spectrum is broken into 11
overlapping channels. Ideally, as you add access points to your network, you want to allow
your coverage areas (or cells) to overlap slightly, so there are no gaps in coverage. Wherever
possible, you should keep a spacing of at least 25MHz (or 5 channels) in adjacent cells, as
shown in Figure 4-2. Otherwise, traffic on nearby APs can interfere, degrading performance.
Figure 4-2. Channels need to be separated by at least 25MHz to prevent overlap and possible
interference
For example, you may use channels 1, 6, and 11 in an alternating pattern to provide complete
coverage without any frequency overlap. Of course, everyone else using 802.11b is trying to
do the same thing, and they will probably be using one of these channels. Especially in a
crowded area, perfect 25MHz spacing may be impossible. If necessary, you may be able to
get away with spacing as close as two or three channels, but don't ever try to run two adjacent
networks on the same channel (things may look fine at first, but will fall apart as the network
load increases).
To figure out what channels your neighbors use, take a look at your signal strength meter and
the other tools that your wireless card came with (the Orinoco card, for example, ships with
Page 36
Building Wireless Community Networks
an excellent Site Map utility). You might also check out NetStumbler, an excellent network
discovery tool for MS Windows. You can get it online for free at
http://www.netstumbler.com/.
The rules are very different when the wires are taken away. Anyone with an 802.11b card can
effectively generate whatever sort of packet they like and send it out to anyone within range.
As long as nodes can agree on a common method of communications, any number of peer-to-
peer networks can be created to exchange data, in a way that makes it prohibitively difficult
for a single entity to impose any sort of restriction on the flow of that data.
IBSS mode is one of the most liberating aspects of the 802.11b protocol. It effectively makes
expensive access point hardware entirely optional, relying instead on each node of the
network to maintain its own communications. Instead of a centralized model, where all clients
must be within range of an access point in order to participate, IBSS allows any node to talk
to any other node within earshot. If one of those nodes happens to be a gateway to the
Internet, it can not only provide access-point-like services but also do the sorts of things that
any self-respecting gateway can do: route packets, throttle bandwidth, act as a firewall, etc.
While IBSS refers to a specific mode of 802.11b operations, you will also encounter a couple
of other similar (but loaded) terms in your travels: ad-hoc and peer-to-peer. A few vendors
have implemented their own "AP-less" mode of operations that, while occasionally providing
some interesting features, don't conform to the IEEE standard and will work only with their
own hardware. These proprietary modes are referred to in product literature as ad-hoc or peer-
to-peer mode. Cards that claim 802.11b compliance may support these additional proprietary
modes, but they must also support true IBSS communications.
To further compound the confusion, the Linux wireless tools package calls any non-AP mode
ad-hoc and lets you choose which one it uses (IBSS or proprietary) via a system call. In the
interest of maximum compatibility, we will be dealing only with true IBSS mode for the rest
of the book, and we'll use the terms IBSS, ad-hoc, and peer-to-peer interchangeably (unless
otherwise specified).
To a Linux machine, the wireless card appears to be just another Ethernet device. The
wireless driver in the kernel provides a network device (e.g., eth0) that can do all of the things
any other network device can do. The rest of the system is completely unaware that
communications are happening over radio. If you have ever built a firewall with Linux, much
of this section should seem familiar to you.
If you haven't built a firewall with Linux, I highly recommend building one with old
fashioned Ethernet to get familiar with the process. O'Reilly's Building Internet Firewalls
Page 37
Building Wireless Community Networks
covers the specific networking issues involved in much greater detail than I have space for
here. Another excellent document to work through is the Firewall and Proxy Server HOWTO
at http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html.
5.1.1 Hardware
Most 802.11b cards on the market today are PCMCIA devices. From a design and
manufacturing standpoint, this is an excellent idea, because it simplifies the production line
and helps keep costs down. At the time of this writing, wireless cards cost anywhere from
$75-$200, with the average hovering around $120. Don't be fooled by their small size; these
tiny cards are capable of sending a signal several miles with the proper antennas.
Obviously, to set up a machine as a wireless gateway, you need a computer with at least one
PCMCIA slot. Although the most common computers that support PCMCIA are laptops, a
desktop or rack mount box with a PCMCIA converter card works just fine. Many vendors
(Cisco and Agere, for example) are selling PCMCIA to PCI or ISA converters specifically to
fit wireless cards into desktop machines.
If you have any doubts about whether your hardware is supported under Linux, be sure to
consult the current Hardware HOWTO at http://www.linuxdoc.org/HOWTO/Hardware-
HOWTO/.
It's also worth noting here that there are a bunch of older 802.11 frequency hopping cards
floating around. They come in both PCMCIA and ISA/PCI packages and, unfortunately, are
not 802.11b-compliant. If you want to be able to support 802.11b clients and data rates greater
than 2Mbps, these cards will not help you. Always look for the "b" before you buy (there's a
reason why the guy at the computer show is running a killer deal on $20 "wireless adapters").
In addition to a PCMCIA slot for the wireless adapter, you'll need an interface that connects
to another network. In a laptop, this is usually provided by a network card in the second
PCMCIA slot, or possibly a built-in modem for connecting to a dialup account. In a desktop
or rack mount machine, any sort of network device can be used, although these days an
Ethernet card is probably the most common (second only to dialup).
As far as actual computing hardware goes, you might consider using an older laptop as a
gateway. It draws less power than a desktop, has built-in battery backup, and typically gives
you two PCMCIA slots to work with. A 486 DX4/100 laptop can easily support several
people as a masquerading gateway, as long as it has enough RAM (16 to 32MB should be
plenty) and isn't doing anything other than routing packets and providing DHCP. We'll design
our gateway to work "headless," so even a working LCD panel won't be a requirement
(assuming your laptop has an external video connector to initially configure it). You can often
pick up older used laptops at thrift stores or computer surplus stores for under $200 (just be
sure to try before you buy; it does need to boot!).
Page 38
Building Wireless Community Networks
The hard disk space required is a matter of personal preference and how much you want the
gateway to do beyond providing access. While a more-than-complete Linux distribution can
fill more than 2GB, you can easily squeeze a fully functional gateway into 20MB or less. In
Section 5.1.10 at the end of this chapter, we'll see some examples of gateway distributions that
fit entirely on a single floppy disk (no hard drive required!).
Of course, if you already have a machine on your network providing firewall services, it's a
relatively simple matter to install a wireless adapter in it and have it serve as a gateway. If you
already have a firewall running Linux, feel free to skip the Linux Distribution section.
For the purposes of example, I'll assume that we're installing an Orinoco Silver card into a
laptop with a small hard drive and an Ethernet connection to the Internet.
Here are things you won't need (and they'd probably just get in the way):
Installing Linux is very straightforward with most modern distributions. Typically, simply
booting from the CD will get the process going. I'll assume that you have the system installed
and running on your existing network for the rest of this section. If you need help getting to
your first login: prompt, there are tons of great references on how to install Linux online.
Page 39
Building Wireless Community Networks
You might start with the wealth of information from the Linux Documentation Project at
http://www.linuxdoc.org/.
Once your system software is installed, you'll need to configure the kernel to provide wireless
drivers and firewall services. The parameters that need to be set depend on which kernel
you're running. The 2.2 kernel has been around for quite a while and has proven itself stable
in countless production environments. The 2.4 kernel moved out of pre-release in January
2001 and is up to 2.4.5 as of this writing. While much more rich in features and functionality,
it is also a much larger and more complex piece of software. For a new installation on a
machine with adequate RAM (at least 16MB for a simple gateway), the 2.4 kernel is probably
the best choice, as more and more developers are actively developing drivers for this
platform. If space is tight, or you have an existing machine running 2.2 that you would like to
turn into a gateway, 2.2 works fine in most cases.
Let's look at the specific kernel parameters that need to be set for each kernel. In either case,
first cd to /usr/src/linux and run make menuconfig. For these examples, we'll assume you're
using either 2.2.19 or 2.4.5. Feel free to compile in any or all of these options as loadable
modules, where applicable.
In addition to drivers specific to your hardware (SCSI or IDE drivers, standard filesystems,
etc.), make sure the following parameters are compiled into the kernel:
• Packet socket
• Network firewalls
• Socket Filtering
• IP: firewalling
• IP: masquerading
• IP: ICMP masquerading (if you want to use tools like ping and traceroute)
Note that you need to enable only the Wireless LAN category, not any of the specific drivers.
This enables the kernel's wireless extensions and provides the /proc/net/wireless monitoring
interface. Don't worry about PCMCIA network drivers; these will be provided by the
PCMCIA-CS package. See the PCMCIA-CS section later in this chapter for details.
Page 40
Building Wireless Community Networks
This enables the PCMCIA/CardBus support category. Under that section, enable the
following:
• PCMCIA/CardBus support.
• CardBus support (only if you have a CardBus network card, i.e., most 100baseT
cards).
• Support for your PCMCIA bridge chipset. Most are i82365, although it generally
doesn't hurt to compile in both.
• Packet socket
• Socket Filtering
• TCP/IP networking
• Network packet filtering
This enables the IP: Netfilter Configurationcategory. Under that section, enable the
following:
• Connection tracking
• FTP protocol support
• IP tables support
• Packet filtering
• Full NAT
• MASQUERADE target support
Under Network device support there are two subcategories of interest. Under Wireless LAN
(non-hamradio):
Support for Orinoco and other Prism II cards used to be provided by PCMCIA-CS (as
wvlan_cs), but has now moved into the kernel itself (as orinoco_cs). Enable Hermes support
if you intend to use one of these cards. Why this particular driver resides here and not under
PCMCIA network device support is something of a mystery.
Page 41
Building Wireless Community Networks
Beyond the above required components, also include the drivers you need for your specific
hardware. If this is your first time building a new kernel, remember to keep things simple at
first. The dazzling assortment of kernel options can be confusing, and trying to do too many
things at once may lead to conflicts that are difficult to pin down. Just include the minimum
functionality you need to get the machine booted and on the network, and worry about adding
fancy functionality later. The Linux Documentation Project has some terrific reference and
cookbook-style material in the Kernel HOWTO at http://www.linuxdoc.org/HOWTO/Kernel-
HOWTO.html. RTFM[1] and encourage others to do the same!
Read The Fine Manual. Thanks to the efforts of volunteer groups like the LDP and thousands of contributors, Linux has
become possibly the best-documented operating system on the planet. And where the Fine Manual isn't available, the source
is. Read it.
5.1.4 PCMCIA-CS
PCMCIA and Card Services provide operating system support for all kinds of credit card-
sized devices, including Ethernet and wireless cards. The PCMCIA-CS package is actually
made up of two parts, the drivers themselves and the utilities that manage loading and
unloading the drivers. The utilities detect when cards are inserted and removed and can give
you status information about what has been detected.
5.1.4.1 Software
If your distribution includes a recent release of PCMCIA-CS, feel free to skip this section.
You can tell what version you have installed by running /sbin/cardmgr -V. I've used 3.1.22
and 3.1.26 successfully. The latest (and recommended) release as of this writing is 3.1.26.
If you need to upgrade your PCMCIA-CS, follow the installation instructions in the package
(it comes with a current version of the PCMCIA-HOWTO). When building from source, the
package expects you to have your kernel source tree handy, so build your kernel first and then
PCMCIA-CS. You can download the latest release at http://pcmcia-cs.sourceforge.net/.
5.1.4.2 Configuration
Setting up radio parameters is very straightforward. All of the wireless parameters are set in
/etc/pcmcia/wireless.opts.
#
# wireless.opts
#
case "$ADDRESS" in
*,*,*,*)
INFO="Default configuration"
ESSID="NoCat"
MODE="Ad-Hoc"
RATE="auto"
Page 42
Building Wireless Community Networks
;;
esac
You may be thinking, "My God, it's full of stars..." But if you have ever worked with
network.opts, the syntax is exactly the same. If you haven't, those asterisks allow for
tremendous flexibility.
The script is passed a string in $ADDRESS that gives details about the card that was inserted,
so you can have different entries for different cards. The address-matching syntax is:
scheme,
socket,
instance,
MAC address)
The scheme allows for setting up as many arbitrary profiles as you like. The most common
use for schemes is on a client laptop, where you may have different network settings for your
office wireless network than for your home network. You can display the current scheme by
issuing the cardctl scheme command as root, and you can change it by using a command like
cardctl scheme home or cardctl scheme office. Both wireless.opts and network.opts are
scheme-aware, allowing you to change your network and wireless settings quickly with a
single command.
The second parameter, socket, is the socket number that the PCMCIA card was inserted into.
Usually, they start with 0 and go up to the number of PCMCIA slots you have available. To
find out which is which, insert a card in one slot and issue the cardctl status command.
The third parameter, instance, is used for exotic network cards that have more than one
interface. I haven't come across one of these, but if you have a network card that has more
than one network device in it, use this to set different parameters for each device, starting with
0.
I find the last parameter, MAC address, very useful because you can match the setting to a
specific MAC address. You can even include wildcards to match a partial MAC address, like
this:
*,*,*,00:02:2D:*)
This would match any recent Lucent card inserted in any slot, in any scheme. Keep in mind
that the wireless.opts is only called to set radio parameters. Network settings (such as IP
address, default gateway, and whether or not to use DHCP) are set in network.opts.
For our wireless gateway example, we'll need to set up an Ethernet card and an Orinoco Silver
card. Include the above code in your wireless.opts. Create entries in your network.opts like
these:
*,0,*,*)
INFO="Wired network"
DHCP="y"
;;
Page 43
Building Wireless Community Networks
*,1,*,*)
INFO="Wireless"
IPADDR="10.0.0.1"
NETMASK="255.255.255.0"
NETWORK="10.0.0.0"
BROADCAST="10.0.0.255"
;;
Be sure to put these above any section that starts with *,*,*,*) because it will preempt your
specific settings. These settings assume that the wired network will get its IP address via
DHCP. You can set DHCP="n" (or just remove the line) and include IP address information (as
in the second example) if your ISP uses static IPs. The examples assume that the Ethernet
card is in slot 0 and the radio is in slot 1. You could also match on the MAC address of your
cards if you want the flexibility to plug either card in either slot, although generally, once
your gateway is up and running. you'll want to forget it's even on. See the PCMCIA HOWTO
for full details on all the tricky things you can do with $ADDRESS.
The excellent Wireless Tools package is maintained by Jean Tourrilhes. You can get a copy
of it online at http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html. He
describes the package as follows:
The Wireless Extension is a generic API allowing a driver to expose to the user
space configuration and statistics specific to common Wireless LANs.
These tools provide a method of controlling the parameters of a wireless card, regardless of
what kind of card is installed (assuming that the wireless card driver uses the kernel's wireless
extensions). They allow you to set the ESSID, WEP keys, operating mode (BSS or IBSS),
channel, power saving modes, and a slew of other options. Simply unpacking the archive and
running make; make install should copy the binaries to /usr/local/sbin (see the installation
notes in the package for more details). The tools currently bundled in Version 21 are iwconfig,
iwspy, iwlist, and iwpriv. They are absolutely necessary for any Linux gateway or client.
Like its networking counterpart ifconfig, the iwconfig tool operates on a specific interface and
lets you view or change its parameters. You can run it at any time from the command line as
root to see what's going on. In addition, PCMCIA-CS calls iwconfig when a card is inserted in
order to set the initial parameters.
Page 44
Building Wireless Community Networks
As you can see, eth0 is a wireless device. The ESSID is set to "NoCat" and WEP encryption
is off. For security reasons, the encryption parameter is shown only if iwconfig is run by root.
If there are any other wireless cards in range with the same parameters set, they can "see" this
node and communications can commence exactly as if they were on the same physical piece
of wire. Run man iwconfig for the full list of parameters. The iwconfig binary should be in a
common binary path (like /usr/sbin or /usr/local/sbin) for PCMCIA-CS to be able to use it.
The other tools allow nifty features like monitoring the relative signal strength of other IBSS
nodes, showing available frequencies and encoding bit rates, and even setting internal driver
parameters, all from the command line. See the documentation for the full details, and there
are more examples in Chapter 7.
For most operations involving a wireless gateway, the iwconfig tool provides all the
functionality we need to program the wireless card. While you're at Jean Tourrilhes' site, also
pick up a copy of hermes.conf and copy it to /etc/pcmcia. It will tell PCMCIA to use the new
orinoco_cs driver (rather than the older wvlan_cs) for all compatible radios. See his site
documentation for more details.
5.1.6 Masquerading
IP masquerading makes it almost trivial to give an entire private network access to the
Internet, while only using one official, registered IP address.
By configuring the gateway's wired Ethernet to use your ISP-assigned address and enabling
masquerading between the wireless and the wire, all of your wireless clients can share the
Internet connection, as shown in Figure 5-1. The internal hosts think they're connected
directly to the Internet, and there is no need to specially configure any applications (as you
would with a traditional proxy server).
Page 45
Exploring the Variety of Random
Documents with Different Content
The Project Gutenberg eBook of Du suffrage
universel et de la manière de voter
This ebook is for the use of anyone anywhere in the United States
and most other parts of the world at no cost and with almost no
restrictions whatsoever. You may copy it, give it away or re-use it
under the terms of the Project Gutenberg License included with this
ebook or online at www.gutenberg.org. If you are not located in the
United States, you will have to check the laws of the country where
you are located before using this eBook.
Language: French
H . TA I N E
PARIS
LIBRAIRIE HACHETTE ET CIE
79, BOULEVARD SAINT-GERMAIN
1872
A LA LIBRAIRIE GERMER-BAILLIÈRE
Il faut donc voir les hommes d'aussi près que possible, et pour
cela faire encore un pas. Nous parlions tout à l'heure de cinq millions
de cultivateurs; mais la population rurale [3] est bien plus nombreuse.
Elle comprend 70 pour 100 de la population totale, quatorze
électeurs sur vingt. En effet, outre les cultivateurs, il faut ranger
parmi les paysans tous ceux qui en ont les mœurs, les idées, les
habitudes, tous ceux dont l'horizon, comme celui du cultivateur, ne
s'étend guère au delà du clocher de la paroisse, c'est-à-dire un
nombre énorme d'ouvriers fileurs, carriers, mineurs, dont la
manufacture n'est pas dans une ville, un nombre très-considérable
de débitants et petits artisans maîtres, charrons, charpentiers,
menuisiers, épiciers, marchands de vin qu'on trouve dans chaque
village, un nombre presque aussi grand d'ouvriers de campagne,
charretiers, manœuvres, sabotiers, forestiers, compagnons, qui,
vivant aux champs, ont à peu près le degré de culture de leur voisin
qui fauche ou laboure.—Or, en France, sur cent personnes du sexe
masculin, il y en a trente-neuf illettrées, c'est-à-dire ne sachant pas
lire ou ne sachant pas écrire. Comme ces illettrés appartiennent
presque tous à la population rurale, cela fait dans cette population
39 illettrés sur 70. Ainsi, l'on ne se trompe pas de beaucoup si l'on
estime à 7 sur 14, à la moitié du total le nombre des électeurs
ruraux qui n'ont pas les premiers rudiments de l'instruction la plus
élémentaire. Voilà déjà un indice d'après lequel on peut apprécier
leur intelligence politique.
[3] On appelle ainsi la population des communes qui ont
moins de 2,000 âmes.
ebookgate.com