Wireless on Linux, Part 1
August 20, 2003
For the harassed, overworked network admin, connecting clients without having to run new cabling is so much fun it feels wrong. Carla Schroder shows Linux admins how they too can join in on the festivities.
For the harassed, overworked network admin, connecting new clients without having to run additional cabling is so much fun it feels wrong. Miles of pretty color-coded cables and tags are aesthetically pleasing and useful, of course, and who hasn't experienced the satisfaction of crimping connectors? There's nothing like the authoritative SNICK of a perfect crimp. (For some of us deskbound-geeks, grip strength is all we have.)
But rasslin' bales of CAT5 cables is like, so last millennium. Hopelessly old-fashioned. Square, even. And wireless Ethernet is no longer new-fangled: it's affordable and works just fine. Today let's take a look at which brands and devices work on Linux; next week we'll dig into the deep, mysterious world of chipsets, configurations, and troubleshooting.
Security and Drivers, or the Lack Thereof
Wireless does have one glaring pitfall, though – security. And then there's the usual Linux pitfall – finding supported hardware. Let's take a moment to wag disapproving fingers of shame at hardware vendors who do not supply Linux drivers for their products. Don't give me any jive about there not being enough interest; there most certainly is a substantial Linux – and Unix/BSD/Mac OS X – market. How do vendors think all those millions of Linux machines are networked? Magic? And Unix was the big networking OS decades before Windows was even born.
And get this — there is a huge pool of talented volunteer programmers who labor tirelessly to write Linux device drivers, often without the cooperation of hardware manufacturers, which apparently do not even want to take advantage of this incredible free labor pool by releasing specs. Shame, shame, shame on these manufacturers.
Neither pitfall is insurmountable, just annoying, and in the case of drivers, inexcusable. Let's start by looking at hardware selection.But first, a tip: do not be shy about returning products that do not work well. The world of wireless chipsets is a chaotic hodgepodge — a single model line may have any number of differing chipsets. Firmware revisions are assigned in a seemingly random fashion to chipsets, which causes variations in features and performance. As most vendors put the burden on the customer to determine Linux compatibility, and offer feeble or no assistance, tough beans on them; keep returning products until they work right.
The first choice is which wireless protocol? Currently, there are three options: 802.11b, 802.11a, and 802.11g. Some devices come with multimode support, but only one of these protocols is compatible with any of the others — 802.11g is backwards-compatible with 802.11b.
My current recommendation is 802.11b, as these products are the best-supported in Linux. However, 802.11b is rated the slowest at a theoretical 11 megabits per second. Here's a quick comparison of the three protocols:
- b and g have the longest range, at up to 150 feet indoors
- a is rated at 75 feet indoors. Outdoor ranges for all three are considerably longer, depending on the terrain. A good signal with a clear line-of-sight can travel a couple of miles
- b and g use the 2.4GHz band, which is crowded (cordless phones and microwaves also use this spectrum)
- a is on the 5GHz band, where there is less interference.
- b is rated at 11 megabits per second, while a and g deliver a theoretical 54 Mbps.
- a devices are the most expensive; b the least.
In other words, don't bust a gusset when your shiny new wireless connection delivers only 5-7 Mbps (802.11b) or 20-30 Mbps (802.11g/a) — that's just the way it is. Another factor is the number of users per access point, as in the case of wireless, it's shared bandwidth, so more users equals slower performance.