Troubleshooters.Com Presents

Linux Productivity Magazine

December 2006

Wi-Fi

Copyright (C) 2006 by Steve Litt. All rights reserved. Materials from guest authors copyrighted by them and licensed for perpetual use to Linux Productivity Magazine. All rights reserved to the copyright holder, except for items specifically marked otherwise (certain free software source code, GNU/GPL, etc.). All material herein provided "As-Is". User assumes all risk and responsibility for any outcome.

See also Troubleshooting Techniques of the Successful Technologist
and Rapid Learning: Secret Weapon of the Successful Technologist
by Steve Litt

[ Troubleshooters.Com | Back Issues |Troubleshooting Professional Magazine ]
One of the ways Microsoft combats piracy is by advising OEMs that they will be charged a higher price for Windows unless they drastically limit the number of PCs that they sell without an operating system pre-installed.  -- Findings of fact: District court for the District of Columbia.

CONTENTS

Editor's Desk

By Steve Litt

This is the toughest magazine I've ever written. Tougher than Troublehooting Professional issues November 2000 (PHP tutorial), March 2001 (XML tutorial), or July 2002 (Simulation). Tougher than Linux productivity issues detailing Perl-Tk, Curses, Spamassassin and IPTables. With all those issues, you could tech-edit them into submission.

This issue is different. Wi-Fi has so many variables, so many different (and often conflicting and broken) tools, and such an odd way of handling state that experiment results are often impossible to reproduce.

Linux drivers for various Wi-Fi devices, and their installation procedures, are so different that each new device is a new learning curve. Most Linux drivers for Wi-Fi devices are in various states of disrepair -- not surprising given the hardware vendors' refusal to share specifications, and product rollout cycles approaching six months.

Then there's the documentation problem. Wi-Fi documentation on the web is contradictory, and often much too cursory, with assumptions that what worked perfectly for the author will work perfectly for you -- an assumption almost always wrong. Speaking of documentation, a search engine search reveals tens or hundreds of people asking the same question as you, but few or no solutions. Finding the solutions amongst the hundreds of questions is a needle in a haystack.

Linux Wi-Fi is hugely frustrating. Sometimes you get lucky and a driver packaged by your distro maker "just works", but many times hours or days of work are required, and on occasions no amount of work produces a working Wi-Fi card.

Politics is another source of frustration. If you try to implement an (often easier) ndiswrapper solution, purists line up telling you all the reasons you should have used a native Linux solution instead of an ndiswrapper linking to the device's Windows driver. They imply that if you have trouble getting wireless to work under Linux, you're not smart, or you're not really dedicated to Linux.

All the preceding frustrations and difficulties are why I spent several weeks writing this Linux Productivity Magazine. Someone needed to write decent documentation for the person not already intimately familiar with the topic. Like other Linux Wi-Fi documentation, this magazine has some errors and some gaping holes, but in my opinion it's a lot better than most, and it really endeavors to help an unfamiliar reader understand Wi-Fi and its Linux ramifications.

The Villains

Many organizations would not benefit finanically by truly OS agnostic Wi-Fi, starting with interoperability's chief enemy, Microsoft. In a world of interoperability and compatibility, why would anyone purchase Windows when Linux is free, zero cost, more stable, more secure, and in many usages higher performance? Microsoft must differentiate or die.

I don't think Microsoft has actively impeded Wi-Fi interoperability. I've heard no rumors of Microsoft encouraging network equipment vendors to place Linux-averse booby traps in their equipment. They don't need to.

Microsoft has (more accurately had, although I doubt much has changed) an operating system monopoly, according to Judge Jackson and the appeals court judge who followed him. Many Wi-Fi hardware manufacturers use that monopoly to gain maximum market penetration with minimum effort. They write Windows drivers for their hardware and call the job done, knowing they've reached 90% of the computer market. Why spend engineering dollars writing Linux/Unix drivers when they could use those dollars to create the next generation product? Can you really blame them? If they don't make it quicker and cheaper, the next guy will.

Even more of a barrier to hardware vendors' release of driver software is free software licensing, which states that anyone receiving free software must have the right to modify it, implying source code availability, and the right to modify it, implying that everyone will have that source code. A smart person possessing the source code for a driver has a tremendous knowledge of the hardware design of the product. In other words, releasing a free software driver could, at least to some extent, compromise the vendor's trade secrets. The same can be true even of a release of the software API documentation. Therefore, the vendor's only choice in releasing a Linux driver might be a proprietary binary driver such as Nvidia's. Then the question becomes, does the vendor want to recompile that driver for different kernels, on into the future? Does the vendor want the responsibility of bug fixes and security updates? All for, at the most, 10% of the market? Does the vendor want to endure the criticism levelled against proprietary binary drivers? This is the backdrop upon which many vendors choose not to support Linux at all.

In response to the situation, the free software community does what they've done for years -- reverse engineer and code. Some vendors release enough API information that free software drivers can be coded within months of the hardware's release. Those products are adopted by Linux users.

Linux and Wi-Fi

For all the reasons stated, Wi-Fi hardware vendors release Windows drivers for their products. Because Wi-Fi is too complicated for the average computer user, those same Windows driver CDs include computer programs to query for basic information and configure the hardware. For a Windows user, Wi-Fi is incredibly simple, because he's never exposed to its complexities.

How different the situation for Linux users. Using only drivers produced through reverse engineering, there are always little problems and gotchas. There's no program to simply set up the hardware. The Linux user must actually know what he's doing, which in the case of Wi-Fi is not simple.

Wi-Fi is Complex

Wi-Fi is a system with voluminous variables, any of which can screw things up.

To start with, it's built on radio communication. If the base station (access point) and the mobile station (wireless NIC) can't communicate because of different frequencies, different modulation techniques, interference from cordless phones and microwave ovens, distance, or solid objects between them, networking doesn't occur. The Wi-Fi neophyte would have no way of knowing why networking failed.

If the radio communication works, the next step is conversion of the radio to IP packets. This requires the correct driver, correctly configured. Sometimes configuration requires a Windows computer (ugh). Configuration can be complex.

Once the radio communication is working, and the drivers are installed, configured and working, you still have all the other networking issues -- subnetting, DNS, DHCP, firewalling and the like. How in the world does a Linux user and Wi-Fi newbie deal with all this complexity -- all these variables, many of which appear as black boxes?

The Linux Way to Learn Wi-Fi

The Windows user can screw in the hardware, pop in the vendor's CD, follow a few prompts, and get wireless working. The Linux user must actually know about Linux and Wi-Fi. Here's my recommended course of action:
  1. Learn basic Wi-Fi terminology and theory.
  2. Set up a proof of concept system, implying you set yourself up a tiny Wi-Fi laboratory.
  3. Incrementally expand on that proof of concept system.
In other words, Rapid Learning at its best. This issue of Linux Productivity Magazine walks you through the preceding three step sequence. It's not as easy as the Windows user's "pop in the CD and answer the questions" method, but you'll have the advantage of becoming an Wi-Fi expert, capable of troubleshooting a wide variety of Wi-Fi problems. Who knows, the Windows guys might hire you to troubleshoot their Wi-Fi problems, armed with your Knoppix CD.

So kick back, relax, and learn Wi-Fi the easy way. And remember, if you use GNU/Linux, this is your magazine.
Steve Litt is the author of Troubleshooting Techniques of the Successful Technologist.   Steve can be reached at his email address.

Is Linux Productivity Magazine Back for Good?

By Steve Litt
Linux Productivity Magazine ceased publication in the summer of 2004, after hurricanes Charley and Frances wiped out our roof and temporarily stopped all Troubleshooters.Com business activities. This is the first Linux Productivity Magazine since then. From now on, Linux Productivity Magazine will be an occasional publication. For that reason the magazines will no longer have volume and issue numbers. From now on, new Linux Productivity Magazines only when I have suitable content and the time to write it.

So check back from time to time. It will be worth it.
Steve Litt is the author of Manager's Guide to Technical Troubleshooting.   Steve can be reached at his email address.

Part I: Learning Wi-Fi

The goal of Part I is to help you learn, not to create a practical wireless LAN. It emphasises repeated Linux installations and attempts to discover the ins and outs of configuring wireless NICs.

Wi-Fi Terminology and Theory

By Steve Litt
Let's start with some very basic terminology.

Term Definition Example sentence
Wi-Fi A system for implementing a Local Area Network (LAN) without wires, using either infrared or radio waves, adhering to the 802.11 specification. Wi-Fi has never been commercially implemented using infrared, but the radio wave version is available as a commodity at your local discount store (Walmart, Target, Costco and the like), as well as computer stores. Wi-Fi is also known, perhaps more accurately, as Wireless Lan. Some say the term Wi-Fi originated as Wireless Fidelity, but I've seen others dispute that assertion. I set up wifi in my house, so now we can all take our laptops anywhere in the house or the back yard and surf the net.
LAN Local Area Network. This is the kind of network you have in your house or one-office business, so that all your computers can talk to each other and share the same Internet connection. My doctor's office just got a LAN so everyone can access patient records from every room.
802.11 This is a specification of transmission of IP packets (TCP/IP) over radio waves (or over infrared, but this was never commercially implemented), using modulation techniques. The 802.11 specification has been modified and augmented several times, including subspecs 802.11b, 802.11a, 802.11g, 802.11n, All my Wi-Fi hardware is 802.11 compliant.
Modulation The act of sending information over a radio wave, where the radio wave is a more or less steady state "carrier wave" and the information is "modulated" on top of it. The simplest type of modulation is AM (Ampletude Modulation), where the carrier wave's amplitude increases and decreases with the transmitted information. The AM band (540-1620Khz) on your radio is an example. Another early type of modulation is FM (Frequency modulation), where the frequency of the carrier wave is varied according to the transmitted information. The FM band (88Mhz-108Mhz) on your radio is an example. There are many, many modulation techniques, each with its own strengths and weaknesses. Modulation techniques used in Wi-Fi includeCarrier Sense Multiple Access with Collision Avoidance (CSMA/CA), orthogonal frequency-division multiplexing (OFDM),  Complementary code keying (CCK),  The 54Mbit/s 802.11g standard uses the orthogonal frequency-division multiplexing (OFDM) modulation technique.
802.11b The first practical extension of the 802.11 standard, this protocol had a 11Mbit/s maximum data rate and a 150 foot range. I have one of those old 11Mbit/s 802.11b access points. You want it for five bucks?
802.11a This "improvement" on 802.11b had a 54Mbit/s maximum data rate, it operated on the 5Ghz range, a band with less traffic for less interference. It also introduced OFDM modulation, which was later used in 802.11g. However, 802.11a has only a 100 foot range, and is incompatible with 802.11b. As a result, 802.11a never really caught on. I've never seen an 802.11a access point.
802.11g Another improvement, popular as a sub $100.00 commodity in 2006, 802.11g had a 54Mbit maximum data rate and a 100 foot range. It uses OFDM modulation, and it's ubiquitous at computer stores, electronics stores, and even discount stores such as Walmart and Target. My entire wireless network is 802.11g compliant.
802.11n As of 2006, this is a proposed modification to the specification. 802.11n is expected to yield extreme gains, with a 540Mbit/s maximum data rate and a 160 foot range. In 2006 there is some "pre-n equipment" for sale, based upon the expected standard. As soon as 802.11n becomes commodity, I'm replacing my 802.11g with 802.11n!
802.11i This 2004 subspecification addresses increased security, and introduces the WPA concept. In our business we've implemented 802.11i in the form of WPA2 with a radius server, but when we travel, we take the security we can get.

So, at the highest possible level, Wi-Fi implements a Local Area Network (LAN) via modulated radio waves. Now let's discuss how that gets done on a box level.

Term Definition Example sentence
NIC Stands for Network Interface Card, also called a Network Card, an Ethernet Card. This is a circuit board attached to your computer's PCI slot or USB slot or some other slot. The NIC accommodates an Ethernet RJ45 connector such that it can be plugged into a LAN's cabling, thereby joining its computer to the LAN. I buy cheapo 8039 based network cards for eight bucks apiece,and they work just fine in my Linux boxes.
Wireless NIC The wireless equivalent of a NIC. This device joins the computer to the local area network not by connecting to cabling, but by receiving and transmitting modulated radio waves. Some plug into the computer's PCI slots, some the USB connectors. Some of the USB wireless NICs have a cable such that the wireless NIC can be positioned for optimal radio reception. Some laptops come with internal wireless NICs. I use Linksys WUSB54G wireless NICs. They connect to my computer's USB port via a cable, so I can move them to get the best signal.
Wireless NIC device name The device name, used in commands like ifup, ifdown, ifconfig, iwlist, and iwconfig, associated with the wireless NIC. Here are several examples:
Name Device type
ath0 Atheros type devices
rausb0 Ralink based devices
bcm0 Broadcom wireless NICs
wlan0 Anything configured using ndiswrapper.
Various device names will be used throughout this document, because at various times throughout this document I was working with either the Atheros wireless NIC built into my Acer Aspire 5100 laptop, the Broadcom bcm4311 built into my Compaq Presario V6133CL, or my Linksys WUSB54G external USB wireless NIC, which is based on the Ralink chipset.
Ad-Hoc mode Ad-hoc mode is a wireless mode of operation where all wireless NICs communicate with all other wireless NICs within range. It's peer to peer networking, that looks like this:
Ad hoc mode

As you can see, Al and Bill's computers communicate directly, as do Bill's and Carl's. Al and Carl might communicate directly, or might go through Bill depending on distances. Bill and Dan communicate through Carl (assuming Bill and Dan are too far to communicate directly).

To put a network card in ad-hoc mode, the following line must be added to /etc/sysconfig/network-scripts/ifcfg-ath0:
Mode=Ad-Hoc

Note

The exact filename and text to be inserted varies between Linux versions and between wireless NICs. Atheros type NICs are called ath0, while rt4500 devices are called rausb0, and all devices installed with ndiswrapper are called wlan0. Note that in all cases, the ending 0 might be 1 or 2 or whatever depending on how many such devices exist.

Ad-Hoc mode is the easiest way to connect two computers with wireless network cards, but as the number of devices increases, you'll want to use Managed Mode.

 At MacDonalds, Jeff and I wanted to transfer files between our notebooks, but there was no wireless LAN there, so we both set our wireless network cards in ad-hoc mode, and did the transfers.
Managed mode Managed mode is not peer to peer -- it's client-server. Each wireless NIC is a client, and the server is a device called the Access Point. 

Here's a diagram illustrating the structure of a managed mode network:
Managed mode
To put a network card into managed mode, include the following in /etc/sysconfig/network-scripts/ifcfg-ath0:
Mode=Managed

Because managed mode is much more practical in a wider variety of situations, the rest of this document will focus exclusively on managed mode.
 In my opinion, managed mode is the way to go if you have more than a few devices on the wireless network.
Access point In a managed wireless network, the Access Point is the server part of the client server relationship. It's probably called an Access Point because it's the point of access for each wireless NIC. Here's a picture of my Linksys WRT54GL access point:
Linksys wrt54g access point
Most access points also have RJ45 connections in order to hook it up to a wired network. Many access points contain other functionalities such as built in firewalls and built in cable modems or DSL modems.

Most access points come with a Windows CD for "easy setup". However, many, including the Linksys WRT54GL, which is still widely available new in late 2006, also have web interfaces, so you can configure them using a computer with any reasonable excuse for a web browser. Unfortunately, the docs supplied with the WRT54GL don't mention the web interface, which by default is available at 192.168.1.1. If you're a Linux guy, be sure to get an access point with a web interface.

Each access point has a unique ESSID. 		In a managed mode wireless network, every device must be in range of the access point.
ESSID Extended Service Set IDentifier.( I've also seen it called Enhanced Service Set IDentifier). This identifies a wireless network, and must be used by any device communicating over that network. It's a case sensitive string with a maximum of 32 characters. To avoid conflicts, it must be unique within radio range, meaning you really should change it from the factory default.

By default, most access points broadcast the ESSID so that clients can list all wireless access points by ESSID, and the user can pick the appropriate one. Many access points can be configured NOT to broadcast the ESSID, so that nobody knows it's there without prior knowledge or sophisticated hacking tools. A client can attach to a non-broadcast ESSID by specifically naming it. Although not broadcasting the ESSID is more secure, it's security by obscurity and should not be relied upon. In fact, with good WPA encryption, the security benefit of not broadcasting the ESSID might be outweighed by the inconvenience.

The terms ESSID and SSID are often used interchangeably, and in most contexts there is no practical difference.		 When I configured my access point, I changed the ESSID to AdamsFamily and set it up not to broadcast the ESSID.
Cable modem A device whose input is cable (like cable TV) and whose output is Ethernet. The proper address translation is performed. If the cable company charges me too much for a cable modem, I'll buy one from Target.
DSL modem A device whose input is DSL (via the phone line) and whose output is ethernet. The proper address translation is performed. If the phone company charges me too much for a DSL modem, I'll buy one from Target.

So there it is. At a conceptual level, a wireless LAN in managed mode is comprised of an access point and several wireless NICs configured in managed mode. Now let's discuss how the wireless NICs connect to their computers via NDIS:

Term Definition Example Sentence
Computer For the purposes of this discussion, hardware., the hunk of metal and semiconductors inside the computer's case. I bought a computer with an Athlon XP 2600, 2GB of RAM, and a 400 GB hard disk. Now I have to load Linux on it.
Operating system The software (computer program) that allows the computer to receive keyboard and mouse input from the user, send video and audio information to the user (monitor and speakers), operate a high level network, facilitate communications between parts of the computer such as disks, memory and the CPU, and run computer programs.

Examples of operating systems include Linux, BSD, Mac OS-10, Unix, Windows. Old but historically important operating systems include VMS, RT-11, RSDOS, MS-DOS, and CPM.		 My favorite operating system is Linux.
Driver A small piece of software to link a piece of hardware to the operating system. The following diagram illustrates a driver for a wireless NIC:
Driver architecture
The preceding diagram illustrates that because the driver interfaces between the piece of hardware (let's call it a device) and the operating system, each combination of device and operating system requires its own driver. Therefore, you cannot use the Windows driver for a wireless NIC if you run Linux, unless you use a clever piece of software called ndiswrapper (more on that later). Likewise, you cannot use a driver meant for a different device (unless the different device has the same chipset and other similarities, making it effectively the same design).

Because the driver interfaces to the device, the driver must have intimate knowledge of the device, or at least a substantial and complete API (Application Programming Interface) to the device. When the hardware manufacturer refuses to release a substantial and complete API of the device, it's very difficult for programmers to create a driver for the mysterious device. This is why it takes so long for new devices to acquire Linux drivers, and why those Linux drivers often implement only a small subset of the device's capabilities. The Linux programmers must guess, reverse engineer, and test, over and over.

Windows drivers appear as soon as the device hits the shelves, because the manufacturer, whose programmers have full knowledge of the device's hardware and API, have a (relatively) easy time coding it, without the necessity of reverse engineering.

What this means is that drivers for many wireless NICs are either buggy, incomplete, or nonexistent. Luckily, some very clever programmers made the ndiswrapper software, which interfaces a Windows driver to the Linux operating system, providing a workaround until the appearance of a high quality Linux native driver.		 I've had trouble finding and configuring a driver for my wireless NIC.
NDIS Network Driver Interface Specification. This is a simplification, perhaps an oversimplification, but NDIS is the Microsoft Windows interface between Windows and the wireless NIC's Windows driver. It's a specification to which most wireless NIC hardware conforms, because it's how Windows does things. See the following diagram:
NDIS architecture
Once again, NDIS is an interface between Windows and an NDIS compliant Windows driver for an NDIS compliant wireless NIC.

Although NDIS is used mostly in Windows, it is a known specification, which means anyone can implement it, at least to a degree. That's how ndiswrapper was created...		 Windows computers interface with wireless network cards via NDIS.
ndiswrapper This software is an adapter -- the software equivalent of a PS/2 to Serial adapter or a USB to PS/2 keyboard adapter. It enables the Linux operating system to talk with an NDIS compliant Windows driver. Since NDIS is how Windows does wireless, that means most commodity wireless NICs. The following is an oversimplified diagram of how ndiswrapper works:
ndiswrapper Linux/windriver interface
The preceding is all you really need to know, but for the curious amongst you, my research indicates that ndiswrapper combines the NDIS API, a Windows Kernel API, and a Linux module to interface the Windows Kernel API with Linux:
ndiswrapper, broken out
In the preceding, the thick rounded rectangle is ndiswrapper.

ndiswrapper isn't perfect. It doesn't reveal/interface to many cards' individual properties or configuration. It doesn't support permiscuous mode, nor the modes Master, Repeater, or Monitor. It supports only modes Ad-Hoc and Managed. Not all settings on all cards will work. Some devices require the extraction of device firmware from the Windows drivers, presenting an extra step and extra software to procure. If there's an excellent native Linux driver for your wireless NIC, that's preferable. If not, ndiswrapper lets you do most of what you need wireless for.

ALWAYS back up your wireless NIC's Windows driver CD to a directory where that directory itself will be backed up, so if years from now you need to reinstall the Windows driver with ndiswrapper, you can find it.

In my opinion, while learning and experimenting with wireless LAN, in other words, while you're a newbie, it's probably best to use ndiswrapper unless your distribution detects your wireless NIC and automatically installs the native driver. Once you're an expert, you can install the Linux native driver. If one doesn't exist, it probably will in a year.

Ndiswrapper is more than a concept, it's an actual Linux command once its package is loaded. Here are some examples, all best done as root:

#### Install Windows driver file mywirelessNIC.inf in your Linux system
ndiswrapper -i mywirelessNIC.inf

#### List installed Windows drivers
ndiswrapper -l

#### Interactively load ndiswrapper
modprobe ndiswrapper

#### Set ndiswrapper to load on boot (careful, changes config files like modprobe.conf!)
ndiswrapper -m

CAUTION: If your distribution has a native driver that doesn't work well, ndiswrapper is your escape route. HOWEVER, in order to deploy an ndiswrapper implementation, you need to completely prevent the native driver from loading. This is typically done by putting this string, assuming the driver to be blocked is the rt2570 driver:
blacklist rt2570
That string goes into the tree searched for drivers to load. In Mandriva Linux it's often put in a file called /etc/modprobe.d/blacklist.

Your Linux friends might advise you not to use ndiswrapper. There's a lot of Linux chauvinism invested in the use of Linux native drivers. But my experience tells me that ndiswrapper works and it doesn't take a guru to install.
 Not finding a decent native Linux driver for my wireless NIC, I used ndiswrapper plus the Windows driver off the wireless NIC's installation CD.

The preceding described installation of the driver. Installing the driver in no way means you can receive Wi-Fi -- association and maybe encryption are necessary for that. What it DOES mean is that you're in position to try to connect to (associate with in Wi-Fi speak) the access point. Before making that attempt, you should run a partial test to see if the driver's working. Type the following command, assuming your wireless network device is named wlan0:
iwlist wlan0 scanning
If there's one or more access points in range, and if your driver is installed correctly, you'll get a list of access points, complete with their essid and other information. Here's an example, obviously performed while writing in a MacDonalds with a Wi-Fi access point:
iwconfig wlan0 scanning
wlan0     Scan completed :
          Cell 01 - Address: 00:0D:3A:23:A7:56
                    ESSID:"MSHOME"
                    Protocol:IEEE 802.11b
                    Mode:Managed
                    Frequency:2.437 GHz (Channel 6)
                    Quality:0/100  Signal level:-85 dBm  Noise level:-256 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0
          Cell 02 - Address: 00:0F:F7:C3:8B:B2
                    ESSID:"Wayport_Access"
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.462 GHz (Channel 11)
                    Quality:0/100  Signal level:-33 dBm  Noise level:-256 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0
          Cell 03 - Address: 00:0F:F7:C3:8B:B3
                    ESSID:"attwifi"
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.462 GHz (Channel 11)
                    Quality:0/100  Signal level:-36 dBm  Noise level:-256 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0
          Cell 04 - Address: 00:0F:F7:C3:8B:B1
                    ESSID:""
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.462 GHz (Channel 11)
                    Quality:0/100  Signal level:-33 dBm  Noise level:-256 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0
          Cell 05 - Address: 00:0F:F7:C3:8B:B0
                    ESSID:""
                    Protocol:IEEE 802.11g
                    Mode:Managed
                    Frequency:2.462 GHz (Channel 11)
                    Quality:0/100  Signal level:-33 dBm  Noise level:-256 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 6 Mb/s; 9 Mb/s
                              11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100
                    Extra:atim=0

You probably won't get that many. I performed that command downtown in a wealthy suburb. You'll probably get only your own access point, but you never know.

Associate The act of connecting the wireless nic of your computer with an access point. A nic can associate with only one access point at a time. With unencrypted access points, association often happens automatically. If it doesn't, you can usually force association to an unencrypted access point with the following series of commands (assuming the wireless NIC's device name is wlan0):
iwconfig wlan0 essid any
ifdown wlan0
ifup wlan0
In the preceding, any is a reserved word meaning any essid. This is very useful in selecting a non-encrypted access point. Occasionally you'll actually have to name a specific Essid, like the following:
iwconfig wlan0 essid <access point's essid>
ifdown wlan0
ifup wlan0
The iwconfig command will tell you whether you're associated or not. If you're associated, and if there are no oddball problems, and if your networking is correct (IP address, netmask, gateway and DNS server, whether hardcoded or served up by DHCP), then you'll probably be able to browse the Internet.

Once you've succeeded with an unencrypted wireless LAN (access point and at least one wireless NIC), congratulate yourself and then get back to work -- you're only half done. Without encryption, your every communication is out there just waiting for the guy in a car parked outside your house to pick off with permiscuous mode. Worse yet, if any computers on the LAN have file servers (NFS, Samba), then the ten year old next door can crawl all over any shared directories on any of your computers. An unencrypted wireless LAN is almost useless.

Nor can your Internet gateway protect you. The Internet gateway prevents people coming in through the Internet, but does nothing to prevent someone listening in on your access point's radio waves. Encryption of those radio waves is necessary.
Encryption Data that's been changed so that a third party intercepting the data can't decipher it. In the case of wireless, it's changing the data sent via the radio waves. I wouldn't be caught dead not having encryption on my business wireless LAN.
WEP Wired Equivalent Privacy, the oldest of commonly used Wi-Fi encryption methods. WEP keeps the kid next door out of your network, but the blackhat parked outside your house can easily crack it, either in its 64 bit or 128 bit personalities. WEP is better than nothing, but you can do better than WEP.

WEP works by creating four hexidecimal keys, each of which is created from a text password. A user gains access by sending in one of those keys, and the key number (1 through 4) of that key. If it's right, the user gets in.

On the Access Point end, you implement WEP by choosing it in the access point's configuration webapp, choosing a password which is then converted to four hexidecimal keys. On the wireless NIC end, theoretically you can implement it by inputting the text password. I have not successfully done that. Theoretically you can also put one or more keys in the device's "up" script, but in my experience that works intermittently at best.

My best success came from creating a script using iwconfig commands:

#!/bin/bash
iwconfig wlan0 key [1] D843288FE2
iwconfig wlan0 key [2] 322489A333
iwconfig wlan0 key [3] F09ABA996D
iwconfig wlan0 key [4] DDF0382EDA
iwconfig wlan0 key [1]
       

# Set key 1
# Set key 2
# Set key 3
# Set key 4
# Make key 1 active


Yes, WEP can keep out the kid next door, but anyone really wanting in could defeat WEP.
WPA Wi-Fi Protected Access. After WEP's insecurities became apparent, WPA was specified. WPA is a framework in which other security measures, such as TKIP, EAP, AES, Radius, and many more. WPA comes in two versions: WPA and WPA2.

My Linksys WRT54GL access point gives the following choices:
  • WPA Personal
    • TKIP
    • AES
  • WPA Enterprise
    • TKIP
    • AES
  • WPA2 Personal
    • AES
    • TKIP+AES
  • WPA2 Enterprise
    • AES
    • TKIP+AES
The "Personal" implementations merely ask for a passphrase. The "Enterprise" implementations require a RADIUS server and therefore require you to input the IP address and port of a working RADIUS server.

On Linux clients, connection to WPA access points is handled by the wpa_supplicant application, which is configured from /etc/wpa_supplicant.conf.		 After learning of the security problems of WEP, I switched my business to WPA wireless security.
TKIP Temporal Key Integrity Protocol. Accroding to my research, this is the most commonly used WPA algorithm for those without RADIUS servers. According to the Linux WPA/WPA2/IEEE 802.1X Supplicant website (http://hostap.epitest.fi/wpa_supplicant/), this is a replacement for WEP, I guess it can be included within the WPA framework. My research suggests that TKIP is much more secure than WEP. I've configured my WPA to use the TKIP algorithm.
AES Advanced Encryption Standard. Another WPA algorithm and replacement for WEP. My research indicates that AES isn't as widely implemented, thus making TKIP a safer choice, at least in 2006. My research suggests that AES is much more secure than WEP. Because I have all modern equipment compatible with AES, I've managed to convert my WPA protected network to the AES WPA algorithm.
RADIUS Remote Authentication Dial In User Service. It's used for many purposes, not just wireless. It authenticates users, and is more secure than WPA plus TKIP or AES. However, it requires a RADIUS server be available 24/7/365, or the wireless network will be unavilable.

Linux, or at least Mandriva 2006, comes with FreeRADIUS, a GPL'd RADIUS server, so you can deploy RADIUS on Linux.		 Now that our business has grown, I'm looking into deploying a RADIUS server and switching to WPA2 Enterprise.
wpa_supplicant This is how Linux does WPA. The 802.1X protocols define a supplicant as a computer seeking authentication from another computer on the LAN (this is an oversimplification, but it's good enough for this article). Linux has the wpa_supplicant project, which compiles to a service (wpa_supplicant), a GUI front end (wpa_gui), and a text front end (wpa_cli). It also contains a utility to convert an ESSID and text passphrase to a hex string suitable as a key.

wpa_supplicant is configured with file /etc/wpa_supplicant.conf. This file contains passphrases and hex keys, so its permissions must be set to 600 (read and write by user, no access by group or other). The following is the code I put at the bottom of the default wpa_supplicant.conf to enable WPA (not WPA2) with TKIP:
network={
        ssid="earthquake"
        proto=WPA
        key_mgmt=WPA-PSK
        pairwise=TKIP
        group=TKIP WEP104 WEP40
	psk=345abcfed22225daee008843fabf4f42345abcfed22225daee008843fabf4f42
	priority=2
}

In the preceding, I created the psk by putting the ssid (essid) and passphrase into wpa_passpharse. Obviously, I changed it before putting it on the net.

The wpa_supplicant command must be run a certain way to successfully attach to a WPA encrypted access point. Here's the script I used:

wpa_supplicant -B -iwlan0 -c/etc/wpa_supplicant.conf \
-Dndiswrapper -P/tmp/ndispid.txt -d -t -K

Here's the meaning of the various arguments:
-B Run daemon in the background
-i wlan0 The interface name (in this case wlan0)
-c /etc/wpa_supplicant.conf The configuration file. For some reason this seemed not to default to /etc/wpa_supplicant.conf.
-D ndiswrapper The wireless NIC driver to be used.
-P /tmp/ndispid.txt A PID file to hold the Process ID
-d Increase debugging verbosity
-t Include timestamps in the debug messages
-K Include keys in the debug output (insecure, get rid of this once everything's set up)

The preceding worked for me -- your mileage may vary.

Steve Litt is the author of Twenty Eight Tales of Troubleshooting.   Steve can be reached at his email address.

Layers of Functionality

By Steve Litt 
When slogging through the ambiguities of wireless NIC installation and configuration, I like to think about it as three layers of functionality:
  1. Driver installation
  2. Association
  3. Networking
I always think of these as layers. You cannot associate until the driver is installed correctly. You cannot network (IP address, subnet mask, gateway, DNS server) until you associate.

I sometimes use the distribution specific tools to accomplish driver installation, but I try very hard never to use distro specific tools, such as drakroam, to associate. Drakroam has unpleasant side effects, including completely rewriting your network device files. As an elder in the Church of the Known State, I really dislike having black box type "helpers" rewrite lots of files willy-nilly, and often unnecessarily.

Driver installation is the procedure you use to install the wireless NIC's device driver. You know your driver is installed correctly when the following command lists nearby access points:
iwlist wlan0 scanning
The preceding command assumes the wireless device name is wlan0. If it's ath0 or rausb0 or something else, just substitute. When the preceding command lists nearby access points, you know the driver is installed, and you can begin trying to associate.

CAUTION

On wireless NICS where you must take the additional step of installing firmware (Broadcom BCM4311, for instance), you can sometimes get an access point listing even though the firmware isn't installed. However, the driver installation is incomplete, and association will be either impossible or highly intermittent under those circumstances.

If you can get a list but association and networking are absent or rarely happen, make sure you didn't forget the firmware step.

Once your driver installation is complete, the next step is association. This is the step in which your wireless NIC attaches itself to an access point. It's often very difficult (especially on the first association after driver installation).

Before continuing on, I like to start with a VERY simple device configuration file:
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

That's it. Nothing extra. Nothing to stop association, and believe me, put one wrong line in there and you won't associate. Any deficiencies in the preceding config file can be compensated by iwconfig commands, either on the command line or in a script.

On my already configured Notebook computer (Compaq Presario V6133CL), I always test for all three layers after boot, as it usually finds and associates with whatever encryptionless access point is stronger. I do this:
ping troubleshooters.com
If the DNS resolves and the pings occur, that's it -- all three layers are fine. If not, I try to associate.

Association is often difficult right after driver installation, or right after having been associated with an encrypted access point. I can usually associate with an unencrypted driver using the following three commands, in the order shown:
iwconfig wlan0 mode Managed
iwconfig wlan0 essid any
ifdown wlan0
ifup wlan0
The ifup command will try to get a DHCP connection (because of the BOOTPROTO=dhcp line in the config file). If it succeeds, you're all done. If not, you might be associated but have network problems (wrong IP address or whatever -- basically bad DHCP if you're using DHCP).

There's no clear way to determine association. However, the following command definitely reveals a lack of association:
[slitt@mylap 200612]$ /sbin/iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:""  
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:00:00:00:00:00   
          Bit Rate:54 Mb/s   Tx-Power:20 dBm   Sensitivity=-121 dBm  
          RTS thr:2347 B   Fragment thr:2346 B   
          Power Management:off
          Link Quality:  0/100  Signal level:-91 dBm  Noise level:-256 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[slitt@mylap 200612]$

Notice the empty string for ESSID and the Access Point address that's all zero? That's a dead giveaway that you're not associated. After you're associated, the ESSID and access point will fill in, something like this:

[slitt@mylap 200612]$ /sbin/iwconfig wlan0
wlan0     IEEE 802.11g  ESSID:"HPPL03"  
          Mode:Managed  Frequency:2.417 GHz  Access Point: 00:20:A6:5B:5E:74   
          Bit Rate:54 Mb/s   Tx-Power:20 dBm   Sensitivity=-121 dBm  
          RTS thr:2347 B   Fragment thr:2346 B   
          Power Management:off
          Link Quality:100/100  Signal level:-49 dBm  Noise level:-256 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

[slitt@mylap 200612]$

In the preceding, note that the ESSID is now filled in and the Access Point address is nonzero. That does not prove association, but at least you know might be associated.
Steve Litt is the author of the Universal Troubleshooting Process Courseware. Steve can be reached at his email address.

Gotchas

By Steve Litt
If you're contemplating installing your first wireless network, don't assume it will be quick or straightforward. It could be days.

The problem is simple. A wireless network with one access point and one wireless nic has hundreds or thousands of variables, and very few testpoints. It's a blackbox. Is your accesspoint transmitting radio waves? You won't know without a working wireless NIC. Is your wireless NIC working? You won't know without logging on to an access point. You're troubleshooting an immense black box.

This article lists some of the gotchas you want to avoid, and how to avoid them.

Allocate Plenty of Time

Maybe you'll get lucky and get wireless networking installed in an hour. If it happens, that's great. But be aware there are plenty of people who have required days to set up their first wireless network. This is a difficult enough task -- don't add to the difficulty with time pressure. Use an experimental computer to host the wireless NIC, so that you won't inadvertenly mess up the computer you depend upon on a daily business. I recommend starting the job on a Friday night, so hopefully you can finish it during the weekend.

Use Windows First

I promise you the day will come when you'll be able to install a wireless network without a Windows computer in sight. However, if you're new to Linux Wi-Fi, that time is not today. As mentioned, A wireless network with one access point and one wireless nic has hundreds or thousands of variables, and very few testpoints. The quicker you can get a known good wireless NIC running and learn how a working Wi-Fi system performs, the quicker you can get the access point running in Linux, with all its functionalities intact, including passwords, IP addresses, DHCP and encryption.

With most wireless NICs, the quickest way to get them running is in Windows. Once the wireless NIC is running, get the access point perfect (using the web interface from Linux), and then get the wireless NIC running on Linux.

Obviously, if you don't have a Windows machine, you'll be forced to ignore this advice.

Find a Known Good Wireless Computer or Access Point

If you don't have Windows and Wi-Fi doesn't work, you don't know whether the problem is your access point or your wireless NIC, and you have no way to find out, because the only way to test the access point is with the wireless NIC, and the only way to test the wireless NIC is with the access point. Ugh!

Things get easier if you have a computer with a known good wireless NIC. Set up the access point to broadcast its ESSID, and then tune in with the known good computer. If the access point is working, the known good NIC's access point list will show the access point's ESSID, strength and encryption technique. If you associate with the access point, then you know how to associate to it with the computer with the wireless LAN you're trying to consider.

In the absense of a computer with a known good wireless NIC, you can take your Linux computer, complete with installations CDs, to the house of a buddy who has a working access point, or maybe a library with a known good access point. Libraries usually have the advantage of no encryption, so that you can get it running in the simplest configuration before trying for encryption.

Consider Using Wireless Detection Tools

The accesspoint/nic catch 22 can be broken down using a diagnostic tool. The simplest is a "hot spot detector", available for about twenty bucks from Target. It has a series of LEDs, and the more that light, the more powerful the signal. Unfortuately, it merely detects the existance of an access point, any access point.

If you're willing to spend $100.00, a better choice is the Linksys WTR54G, a "travel router" that can pick off wireless signals from the air and send them into your computer via a standard wired NIC. Within the travel router's firmware, completely independent from your computer, a web page lists all access points, with encryption and signal strength. You'll know the exact environment in which you're attempting to install your wireless NIC's drivers, and associate with an access point.
Wtr54g personal router
Linksys WTR54G Personal Router

A really cool thing about this travel router is that, at least for unencrypted access points, it can serve as a wireless NIC, drivers not needed. It's a great "plan B" in case you can't install a wireless NIC. If this travel router could deal with decrypting encrypted access points, I'd recommend just buying one and forgetting about interfacing a wireless NIC with Linux. The WTR54G costs about a hundred dollars, and I'm glad I bought mine.

Don't Put the Wireless NIC Too Close to the Access Point

When doing your experimentation and setup, try to keep the wireless NIC about 5 feet from the access point, and make sure there's nothing between them. My first experiments were with the wireless NIC and access point maybe 5 inches from each other. At such tiny distances, they overload each other so that when you look for access points, you don't see the access point at all.

When radio connectivity defeats you, you cannot tell that you're being defeated by radio connectivity. You could just as easily surmise it's a driver problem or a silly network config problem. Your best chance for great radio connectivity every time is a 5 foot distance between them, with perfect line of sight between them. Once everything's set up, you can probably use your wireless LAN with the access point in a bedroom, and a wireless NIC in the back yard, front yard or living room. That's fine, but until you've ironed out all the variables, keep them at the distance most likely not to cause problems.

Put Your Antennas Up

For all the reasons enumarated in the preceding two paragraphs, keep your antennas up on your access point and your wireless NIC.

Use an Experimental Computer

Don't use your daily driver computer to set up your wireless network card for the first time. Or the second, or the third. At least in Mandrake, the distro-specific utilities to set up wireless rudely mess with your wired ethernet connection, and almost everything else about networking. You'll be confronted with problems you've never seen before, and it will stop your daily work if it happens on your daily driver computer. If it happens on an experimental computer, if worst comes to worst you can reinstall the OS and be done with it (assuming your OS is BSD, Linux, or pre-XP Windows).

With an experimental computer you'll feel more confident when doing experiments, because you lose nothing if you wreck the whole OS. Things go much quicker. With an experimental computer, you can even reinstall the OS to see if it autodetects the wireless NIC. Sometimes autodetection is better during installation than afterwards.

The ideal experimental computer will have several Linux distros, each with plenty of disk space (for placing the packages for the distro so you don't need to CD flip). Ideally, it would even have Windows so, with the same hardware, you could compare Linux results to Windows results.

Use an experimental computer if at all possible. Try very hard not to use a computer important in your daily activities.

Back Up Your Old Network Setup

As mentioned, your distro's wireless setup tools mess with ALL your network configurations -- often doing it wrong. Before beginning to install a wireless NIC on a Linux box, back up the /etc directory to a tree somewhere else. Then, when you start having strange problems, you can see what changed and fix things.

Distros Do Wireless Completely Differently

Google "WIRELESS_ENC_KEY", and 80% of the results involve Mandriva or Mandrake. My reading indicates that config parameter exists only in Red Hat and its spinoffs (Mandrake/Mandriva being the most important).

At First, Use Your Distro's Wireless Setup Tools

After hearing about how the distro's wireless setup tools run roughshod over your entire network configuration, you might wonder why I recommend using them. For three reasons:
  1. They provide a time saving quickstart.
  2. They automatically install the needed drivers, with at least some autodetection.
  3. You can learn from and reverse engineer the statements they put in your network scripts and other files.

Later, Do Not Use Your Distro's Wireless Setup Tools

As discussed, your distro's wireless setup tools modify all sorts of files, willy nilly. Also, your distro's wireless setup tools are distro dependent, so you need to learn many of them.

Several free software projects give you dependable, distro independent wireless setup methods. Some handy projects include:

dhcp-client Tools for obtaining an IP address, subnet mask, gateway and DNS server address from a DHCP server.
wireless-tools iwconfig and several other programs to query and modify the state of a wireless device.
ndiswrapper An adapter program to adapt your wireless NIC's windows driver to Linux, thus being able to use your Windows driver in cases where the native Linux driver is defective or nonexistent.
wpa_supplicant A program for authenticating against access points with wpa encryption, together with tools like wpa_cli, wpa_gui and wpa_passphrase, to help you configure and diagnose.

Use ifup and ifdown

Whenever you make a change in networking, use the ifdown and ifup to restart your network interface and test your changes. To restart your wlan0 wireless lan, do this:
ifdown wlan0
ifup wlan0
To restart your wired ethernet (eth0), do this:
ifdown eth0
ifup eth0

Watch Out For State Dragaround

Perhaps the ugliest thing about experimenting with a wireless NIC is that, when you make a change, you're never sure how far you need to go to fully implement that change. Should you just ifdown and ifup the device? Should you do a full /etc/init.d/network restart? Should you restart other services? Should you reboot the machine? Should you go searching for miscellaneous persistent files containing the old state, and update or delete them?

Unfortunately, at one time or another, each action in the preceding paragraph is necessary, yet at other times lesser actions will be quite sufficient. Unfortunately, the way wireless is implemented in Linux, there are many little places where state is retained, meaning after you make a change, the old state can still come and bite you. Here are some of the places old states like to hang around:
All the preceding tend to drag the old state around. Actually and worse, they drag some of the old state around, so things aren't even consistent. One state store thinks you're using encryption, while another thinks you're not -- a guarantee of frustrating failure.

I created a script to killall on ifplugd, wlandetect, zcip and dhclient. before performing a wlandetect and /etc/init.d/network restart, and then performing some pings to see if it worked. So far, my research tells me that I can delete the files in /etc/sysconfig/networkscripts/wireless.d/*, because my research tells me they're extra copies to make things easier, but if you use an editor for configuration, my research tells me they're extraneous. Of course, I could be wrong.

/etc/wpa_supplicant.conf is definitely NOT extraneous, especially if you're using encryption. It's the best way Linux does encryption, although from my reading many drivers can't yet use it. There's a wpa_supplicant software package to handle this. It's complicated.

And, of course, there's the problem that each distro's config tools rewrite all these files willy nilly, but in Mandriva 2006 and 2007, not necessarily in a state consistent manner. In my opinion, once you have a good understanding of wireless, you should not use the GUI tools.

The bottom line is this. As you experiment changing config files, you must be very careful that the changes made to the config files completely and consistently change the state of the system. Otherwise, you'll draw wrong conclusions, and go around in circles. In my opinion the best thing to do is create (probably by trial and error), a script to clear out all old state information, and then restart your interface (or perhaps the entire network). Once you get a script you really trust, learning will be much faster.

Oh, and speaking of really trusting your script -- never trust it completely. There will always be some new and interesting gotcha.

Prefer Runtime Scripts to ifcfg Files

The ifcfg-* scripts depend on a whole lot of other scripts, many of which can be wrong for the situation or just plain wrong. Using bash scripts with iwconfig commands and other commands can sometimes be more reliable. As a matter of fact, for receiving 64 bit WEP encoded wifi on my Linksys WUSB54G, I found a minimal ifconfig-wlan0 plus a script works very well. Here's my minimal ifcfg-wlan0:
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes
       
Name the device
Get IP, gateway and DNS dynamically
Bring up on boot

The preceding can't possibly bring up an encrypted network -- there are no keys. All it does is provide a framework such that if there's an access point connected to a subnet with a DHCP server with valid gateway and DNS server, then if you get the keys right you can tune into WEP. For the keys, I use the following connection script:
#!/bin/bash
iwconfig wlan0 key [1] D843288FE2
iwconfig wlan0 key [2] 322489A333
iwconfig wlan0 key [3] F09ABA996D
iwconfig wlan0 key [4] DDF0382EDA
iwconfig wlan0 key [1]
       

# Set key 1
# Set key 2
# Set key 3
# Set key 4
# Make key 1 active

I'm sure you know this, but the preceding keys are falsified and won't work in my network. I'm sure you know this also, but you must not use the key values above, or you'll be vulnerable to script kiddies looking for access points with well known values (I believe the popularity of this LPM issue will make the preceding well known). In other words, you must generate your own keys.

When you run the script, all of a sudden the wireless NIC comes alive, complete with DNS and Internet. I would have thought it necessary to at least run ifup on it, but for whatever reason it simply comes alive. If that doesn't happen in your case, run ifup on the interface.

As you read more and more on the Net, you'll see that most people resort to workarounds like this for wireless. It's not ideal, but usually turns out to be the easiest and most carefree. The GUI tools from your distro vendor are nice for learning in broad strokes, but they screw things up, and as you become more knowledgeable you'll probably agree with me that scripts work better and have less unpleasant side effects.

Be Careful With Security

If a visitor to your house is given root for a few minutes, he can have your wireless keys. First, when run by root, the iwconfig command lists the current key in use. And, of course, any config files can be looked at.

Always make sure any scripts or config files containing passwords have only root access, including read access. Make sure nobody gets your root password, because with it they can access the entire network.

Install the wpa_supplicant Package

The wpa_supplicant package is the best hope you have for doing WPA and WPA2 encryption. Make sure to install it.

Read the Wireless Tools Documentation

The wireless-tools package includes iwconfig, iwspy, iwlist, and several others. Once you get a little understanding of wireless and Linux wireless, you'll probably start substituting scripts comprised of the wireless-tools package for your distro's handy dandy GUI tools and proprietary network startup scripts. You can read the wireless-tools documentation here (on Mandriva and probably other distros):
/usr/share/doc/wireless-tools-28
Of all the documents there, one's especially a must-read: HOTPLUG.txt. This document explains lots of the conundrums you encounter when using wireless.

Don't Underestimate ndiswrapper

Purists shun ndiswrapper. They say native Linux drivers work better. They say Linux drivers are more secure. They criticize the use of the Windows driver because it's a blob of code without source code. And if you read between the lines, some imply using ndiswrapper makes you a Windows Weenie and a traitor to Linux.

Here's the truth of the matter. Some Linux drivers work better, and some work worse. A lot worse. The can intermittently drop connection, freeze the computer, or a host of other irritations.

Linux drivers are more secure if they're more secure than the Windows driver they're replacing. Linux drivers are usually built by one or two developers who must work around a full time job. There's no guarantee the Linux driver is more secure.

It's true indeed that a Windows driver is a sourceless code blob. In a perfect world such sourceless code blobs wouldn't exist. This isn't a perfect world.

As far as the implication that using ndiswrapper makes one a Windows Weenie and traitor to Linux, that's laughable. The person installing Wi-Fi on Linux must overcome Microsoft's inoperabilities and lack of standards, and the hardware vendors lack of Linux support and in some cases Linux hostility. That's what I call dedication to Linux.

Now let's discuss the benefits of ndiswrapper:
My experience is that if you can find the right Windows driver, ndiswrapper usually works. Finding the right driver is easy if the vendor gave you a driver CD. It's a little harder otherwise. With Broadcom, good luck -- they list their drivers by manufacturer and model of computer, not by model of the wireless NIC. But with most manufacturers, you can get a driver that works with the device and with ndiswrapper.

Some devices, most notably the Broadcom 43xx series, require you to extract firmware from the driver set and put it in special directory /lib/firmware. For the Broadcom 43xx series there's even a program called bcm43xx-fwcutter, available for download and simple compilation, that does this for you.

Native Linux drivers often aren't all they're cracked up to be. Read their project site documentation. Many are alpha, and warn of instability. Many don't support the maximum data transfer rate, dropping you back to 11Mbs, which is so 2002. Others don't support WPA or WPA2. On the other hand, most ndiswrapper implementations support most of what the Windows driver supports, which is usually the full capability of the device.

Last but not least, after you make a few ndiswrapper installations, things get much easier. You begin to know how to do it, even in the absense of documentation, or more likely, facing several pieces of conflicting documentation.

The ndiswrapper program is much more than a driver of last resort. It's often your easiest path to success, and often produces the best results. Here's what I do. I spend maybe an hour trying to install the native driver. If I can't do it in an hour, it will probably take over a day, so I just use ndiswrapper.

Know Your ifcfg Config Lines

If you use your distro's wireless NIC setup tools, it's very likely to alter (and not necessarily for the better) the ifcfg-* files in your /etc/sysconfig/network-scripts directory. It's very helpful to know the config lines that go in these files. The lines are the same, or similar, for both wired and wireless networking.

The following are lines that are in almost every ifcfg-* file. They're typically necessary for proper interfacing to your local area network.

DEVICE= eth0, eth1, wlan0, ath0, bcm0, rausb0 etc. The name of the device. This should be the first line in the config file (ifcfg-whatever). If it's not the first, there's a chance that the ifdown or ifup commands could error out.
BOOTPROTO= static, dhcp or none static means you'll be defining the device's IP address, netmask, gateway and DNS server. dhcp means those elements will be gotten from a dhcp server. none means disable the device.
IPADDR= 192.168.100.44 (for instance) Defines the IP address of the device. If BOOTPROTO=dhcp, this config line is ignored. That's a good thing, because if you set up your ifcfg files right, you can switch from hard to dhcp by changing nothing but the BOOTPROTO= line. Be aware that many distros' network config tools blow this line off if BOOTPROTO=dhcp.
NETMASK= 255.255.255.0 (for instance) The netmask. You should have already learned this, if not look for other documentation.
BROADCAST= 192.168.100.255 (for instance) This defines the subnet's broadcast address -- an address at which every NIC on the subnet will receive the data packets. Remember, the subnet is the IP address ANDed with the netmask. For instance

192.168.100.44          10.4.8.200
255.255.255.0          255.0.0.0
--------------         -----------
192.168.100.0           10.0.0.0

Once you know the subnet, the typical broadcast address is obtained by substituting 255's for the trailing zeros.
GATEWAY= 192.168.100.88 This line defines the "escape route" from your subnet -- how you get out to the Internet, or to another network. In a home or small office environment, this is typically the IP address of the Internet router, cablemodem, or IPCop box.

If you encounter a symptom where you can ping other machines on your subnet (local area network), but can't ping anything on the Internet, check that you can ping your "escape route", and if you can, check that this line exists and is correct.

The following are some config lines that, while not necessary, often help things along.
ONBOOT= no or yes If yes, the interface will be up on boot. If no, it will be down on boot, and you'll need to manually put it up with ifup or by restarting the whole network.
USERCTL= no or yes On a desktop, I keep this as "yes" so I can use ifdown and ifup on the interface without needing to become root. On a server with lots of users, obviously you don't want individual users messing with the network connection.
PEERDNS= no or yes If yes, the DNS server for this computer serves out DNS for the computers on its LAN. Let's say you have a wired LAN in your office, and another wired LAN for your kids, but those two LANs (which are all on the same subnet) communicate over wireless because you don't want to string cat 5 across your living room ceiling. You can have one of the kids' computers get its DNS via DHCP, and then serve that DNS out to the rest. I'm not sure I know why you'd want to do that, but...
PEERYP= no or yes Same concept, but for YP (NIS). Given the security problems of NIS, I think no, which is the default, would be an excellent answer.
PEERNTPD= no or yes Same concept, but for a time server.
HWADDR= 00:0f:b0:48:10:1f (for instance) The mac address of the device. I'm not sure why this is necessary or desireable -- networking works without it, but here it is. Maybe it's a security thang.
METRIC= 10 (for instance)
DHCP_CLIENT= dhclient,
NEEDHOSTNAME= no or yes Things can get ugly fast if you say yes. On Mandrake, this can prevent you from bringing up the interface. What it's supposed to do is enable your computer to get its hostname from the DHCP server, instead of having it hard coded. Why in the world would you want an everchanging hostname? I hear some ISPs require it, but, oh, it can get ugly.
MII_NOT_SUPPORTED= no or yes
Steve Litt is the author of Twenty Eight Tales of Troubleshooting.   Steve can be reached at his email address.

Overview of an ndiswrapper Wireless NIC Installation

As mentioned many times in this magazine, ndiswrapper is often a high quality alternative to native Linux drivers. The ndiswrapper alternative also has the advantage of installing similarly across different devices. This article discusses a generic ndiswrapper installation using only command line, distro independent tools.
  1. Obtain necessary software
    1. Windows driver
    2. cabextract
    3. dhcp-client
    4. wireless-tools
    5. wpa_supplicant
    6. ndiswrapper
    7. Firmware extractor (like bcm43xx-fwcutter) if firmware extraction is needed
  2. Install the driver
    1. su -
    2. cd <directory with drivers>
    3. Extract drivers from .exe collection if necessary
    4. Extract firmware to /lib/firmware/ if necessary (for instance, Broadcom 43xx)
    5. ndiswrapper -i drivername.inf
    6. ndiswrapper -l
    7. ndiswrapper -m
    8. depmod -a
    9. tail -fn0 /var/log/messages (in another terminal)
    10. modprobe ndiswrapper
  3. Test the driver
    1. Verify existence of simple wlan0 config file
    1. Create the wlan0 config file if necessary
    1. iwlist wlan0 scanning
  4. Connect (associate) to an access point
      1. iwconfig wlan0 mode Managed
      2. iwconfig wlan0 essid any
      3. ifdown wlan0
      4. ifup wlan0
      5. Wait up to a minute
      6. ifconfig wlan0
        1. Look for IP address, which indicates association and DHCP success
      1. Create a connection script
      2. Run the connection script
  5. Verify IP, netmask, gateway and DNS
    1. ping troubleshooters.com
    2. Troubleshoot as necessary
  6. Troubleshoot

Obtain necessary software

To use ndiswrapper, you need a Windows driver for the wireless device. You can get this from the CD that comes with the device, or from the device's manufacturer's website, or from the computer manufacturer's website. If your kernel is 32 bits, you must have a 32 bit Windows driver. In my opinion, finding a good Windows driver compatible with ndiswrapper is by far the toughest challenge of ndiswrapper configuration.

Occasionally, especially if you download the driver from the Internet, the driver comes packaged in a .exe archive. To extract the drivers from the archive, use the cabextract program, available on the Internet, or sometimes you need to use the unzip program. Building and installing it after extracting its source from the tarball typically is as simple as ./configure;make;make install.

Some devices, most famously the Broadcom bcm43xx series, require you to extract "firmware" from the set of driver files (probably a .sys file), and place those drivers in /lib/firmware. Note that this does not permanently flash the device. It's not like "flashing your computer's bios", where one slipup can render your motherboard forever inaccessible. In the case of wireless NIC "firmware", at least with the Broadcom bcm43xx series, the applicable contents of /lib/firmware are transferred to the device's flashable ROM every boot, so you can change the "firmware" at will just by changing what's in /lib/firmware.

If you have a Broadcom device, you can compile bcm43xx-fwcutter after extracting its tarball with make;make install. The following is the command to extract firmware from mydevice.sys to /lib/firmware:
bcm43xx-fwcutter -w /lib/firmware mydevice.sys
Your distro might include a bcm43xx-fwcutter package. I'd advise getting the latest source and compiling. The bcm43xx-fwcutter that came with my Mandriva package did not work with a modern and crucial driver, but the newest version, downloaded and compiled, did.
INFORMATION

With most wireless devices, you won't need to extract firmware, Broadcom 43xx hardware being one of the exceptions. Often you also won't need cabextract, because your driver set is not packaged in a .exe archive.

The dhcp-client package is necessary to receive IP, netmask, gateway and DNS information from a DHCP server. The dhcp-client will almost certainly be provided with your distribution, and will probably already be installed. Check for the existence of executable file dhclient to confirm that it's installed, and if not, install it.

The wireless-tools package contains essential executables iwlist and iwconfig, and is therefore foundationally essential to working with wireless. It's contained in all major distros. Install it.

The ndiswrapper package contains the ndiswrapper executable, the lynchpin of wireless NIC installation using Windows drivers. Your distro probably has it -- make sure it's installed. I've read some anecdotes that your distro's ndiswrapper might not be up to the job, and that you should get the latest from the project website. I've had excellent luck with the ndiswrapper package that comes on the Mandriva install DVD, so I'd suggest you use the one from your distro unless your distro is terribly old, or unless you've eliminated other causes for failed installation.

Install the driver


su -
 You must be root to do most of this stuff 
cd <directory with drivers>
 Makes the rest of the commands easier 
cabextract mydriver.exe
 Takes an .exe archive and extracts its contents, thereby making driver files available. Necessary only if your drivers are packaged in a .exe file. If cabextract reports no cabinets, try the unzip program. 
bcm43xx-fwcutter -w /lib/firmware mydriver.sys
 Extracts firmware files from mydriver.sys and places them in /lib/firmware. This is necesary only on drivers requiring firmware extraction. For most drivers, you can skip this step. 
ndiswrapper -i drivername.inf
 Places a copy of several driver files in the /etc/ndiswrapper tree. 
ndiswrapper -l
 Should list the windows driver associated with drivername.inf. Should say that both the driver and the hardware are installed. If not, there's a problem. 
ndiswrapper -m
 Places a line in either /etc/modprobe.conf or /etc/modprobe.d/ndiswrapper or both in order to restart the driver at boot time. The line should look something like this:
alias wlan0 ndiswrapper
 
depmod -a
 This regroups all modules so that all dependencies are accurate. This is necessary before installing a new module. 
tail -fn0 /var/log/messages
 This realtime log prints all new log messages. Do it in a different terminal so you can see the results of the next command. 
modprobe ndiswrapper
 This installs the driver. If all goes well, you should see something to that effect in the realtime log. The realtime log might complain about not finding a link. That's OK, it simply means you haven't associated with an access point, which of course is to be expected. Any other errors should be investigated, as should a lack of messages saying what encryption modes wlan0 supports.

One insideous problem crops up often -- an installed native Linux driver stomping on your ndiswrapper driver. This can have intermittent symptoms or reproducible symptoms, and can be very mysterious. If you can get the name of the native Linux driver you can disable it with a blacklist command (see troubleshooting section)

Test the driver

An installed driver gives you very little capability. All you can count on is being able to list nearby access points using this command:
iwlist wlan0 scanning
If the driver's installed correctly and there's at least one nearby functional access point, the preceding command will list access points. If it cannot list access points and you know there's a functional one nearby, your driver isn't installed correctly. If the command does list access points, your driver is probably installed properly, although I saw one case where it could list but the driver was installed wrong, specifically the Broadcom firmware was not installed.

Connect (associate) to an access point

You might get lucky. I doubt it right after an install, but try it:
ping troubleshooters.com
If the preceding command resolves troubleshooters.com to an IP address and successfully pings it, you've associated and all network parameters are correct, and you're done. In most cases you won't get that lucky right after installation.

To associate with an unencrypted access point, perform the following set of commands:
iwconfig wlan0 mode Managed
iwconfig wlan0 essid any
ifdown wlan0
ifup wlan0
You can verify that you got an IP address with this command:
ifconfig wlan0
Notice the preceding command is ifconfig, not iwconfig.
If the preceding doesn't work, try this:
iwconfig wlan0 mode Managed
iwconfig wlan0 essid <essid of access point as listed by iwlist>
ifdown wlan0
ifup wlan0
If the preceding didn't work, try rebooting and waiting a few minutes. Remember, you go through all this hassle only after driver installation. Once you've associated with an unencrypted access point, your computer should be able to automatically associate with any properly configured unencrypted access point.

Verify IP, netmask, gateway and DNS

Associating with an accesspoint will give you an IP address, netmask, gateway and DNS server if and only if you've configured the device as a DHCP client (BOOTPROTO=dhcp or similar in various distros), and if the access point's DHCP server (or another DHCP server on the access point's LAN) is set up properly. Start by seeing if you got lucky:
ping troubleshooters.com
If the preceding resolves troubleshooters.com to an IP address and pings that IP address successfully, you're done. Otherwise, you need to see where you're falling down on the job.

The first step is to see if you have an IP address:
ifconfig wlan0
Another handy test is iwconfig to see if you have an essid and a nonzero access point address. If not, you're definitely not associated. If you have an essid and nonzero access point address, you might (or might not) be associated.

If the result includes an IP address (inet addr), then at least the DHCP server gave you an IP address. Ping that address, and it should work OK. Ping the broadcast address like this, assuming you've been given IP address 192.168.1.5:
ping 192.168.1.255
or
ping -b 192.168.1.255
If you get any addresses other than yours, you're connecting to the access point's LAN, which is a good thing.

Sooner or later, you'll need to strongarm values of gateway and dns server, in order to determine what's broken. Put IP address of a known good DNS server in /etc/resolv.conf, and see whether IP addresses now resolve. If IP addresses now resolve, the DHCP server is probably giving you a bogus DNS server address -- notify the system administrator of the access point.

If the access point is your own, and you have control over the LAN it's connected to, you can read that access point's address from the access point's configuration software (probably a web interface). Then you can change your client computer's wireless network device's config file, something like this if your network's internet gateway is 192.168.1.200 and address 192.168.1.15 is not currently used or in a DHCP lease range:
BOOTPROTO=static
IPADDR=192.168.1.15
GATEWAY=192.168.1.200
Another thing to look for is that the LAN encompassing the access point might have multiple DHCP servers, which is usually not a good idea. For instance, the LAN might have already had a DHCP server, and then the access point was added, and the access point's DHCP server was enabled.

Troubleshoot

Wi-Fi is way too complex to cover with a predefined diagnostic. Instead, this section offers some tips to make troubleshooting easier.

Log Files are Your Friend

Log files enable you to look back in time and do detective work. Error messages typically point you in the right direction, and might be valuable as search engine search terms. You can also view them in real time by using the -fn0 option of the tail command before running processes you expect to log something. The dmesg command also gives good log information. Look in your /var/log directory for recently updated log files (ls -ltr /var/log/*), and tail the logs into a pager (less).

Wireless NICs can be gigantic black boxes. Log files help you peer inside.

Pay Attention to Your Layers of Functionality

Note the article called Layers of Functionality. If the driver doesn't work well enough to list nearby access points, you cannot possibly associate or browse the net. Don't troubleshoot association problems or IP address/gateway/dns problems until you can at least get the wireless card to list nearby access points.

Strongarm IP Addresses

If you're having trouble associating or browsing, maybe the DHCP server sent by the access point has problems. To the extent that you have known good IP addresses, try strongarming the IPADDR and GATEWAY lines of your device's config file. Strongarm the IP address of a known good DNS server into /etc/resolv.conf, above the line magically inserted by DHCP. If problems go away, either you or the access point has a DHCP problem.

Find a Tiebreaker

One of the toughest Wi-Fi situations is when you have one access point and one client computer with wireless, and you can't tell which is malfunctioning. In such case, try to find something else that will break the tie and at least partially indicate which is working right and which is working wrong:

Have Some Pre Resolved IP Addresses

It can't resolve and can't ping, but here's the question -- could it have ping'ed if it could have resolved? If you have a list of known IP addresses for various websites that can be ping'ed, then even in the absense of DNS you can test connectivity with ping. Also, have IP addresses of a few known good DNS servers to plug into /etc/resolv.conf in order to test DNS.

If you haven't previously created a set of known good IP addresses, you can sometimes find them in your caching DNS setup. For instance, if you use djbdns, look for root server addresses in /service/dnscache/root/servers/@. If you cannot ping those addresses,  either your Wi-Fi isn't working, or perhaps your Internet gateway isn't working. Pinging local (non-Internet) addresses should shed further light.

Don't Hesitate to Reboot

Linux chauvinists bristle at this suggestion, but if your time is valuable, you might want to reboot every once in a while. I've had situations where, after dinking around for an hour, I rebooted, and bang, Wi-Fi worked. Rebooting is the best way around to get your computer into a known state, so sometimes you need to use it. This is especially helpful in resolving problems with state dragaround.

Back Out Ndiswrapper

Sometimes you get yourself so bollixed up it's best to back out and try again. Fortunately, it's not hard:

Search the Net

Notice I didn't call this "the net is your friend", it isn't. Thousands of dweebs go on mailing lists saying "I get an error message saying "could not find link", what could it be". Probably one in a hundred finish off the thread with a thank you saying what worked, and even better, put <SOLVED> in the subject. Nevertheless, I've found that browsing the net can give me new ideas and get me off dead center when troubleshooting. It's the old "how do I narrow this down one more time?" mantra.

Thoroughly Understand ifconfig, iwconfig and iwlist

These three programs are your view portal into the Wi-Fi black box. Understand them, both as read and write tools. These tools are like a microscope and tweezers to a biologist. Learn them, and use them.
By Steve Litt Steve Litt is the author of many books. Steve can be reached at his email address.

Part II: Using Wi-Fi

Learning Linux Wi-Fi involves voluminous experimentation. The goal is not to quickly set up networking, but instead to learn. It's (hopefully) done on experimental machines, where Linux can quickly be reinstalled if things go really haywire. While learning, the distribution-provided GUI config and installation tools are useful as learning tools.

Once you actually want a working Linux Wi-Fi, priorities change. It's done on your real computer, so the unknown side effects perpetrated by distro specific tools are unacceptable.

General Installation Guidelines

By Steve Litt
Depending on the distro and hardware you use, this could take 15 minutes, or it could take 8 hours (or more). Be VERY patient. I think it's a good idea to install a Wireless NIC before installing the access point. That way, when you install the access point, you'll be able to listen for it.

This article uses Mandriva 2006 Linux as an example, because that's what I use on a daily basis. As far as I know, all full featured, modern distros include tools to ease the installation of a wireless NIC, and in my opinion, if you're a relative wireless newbie, you should use them.

Safety First!

Before you even plug in your wireless NIC, you have two safety concerns -- one to prevent a big hassle, the other to prevent theft of your data.

Preventing Data Loss

When you use a wireless network, unless you've taken steps to secure it, any fool with a laptop can park in front of your house and intercept everything you send over that network. Worse still, he can barge into your hard disk (using NFS or Samba or FTP, he can send spurious email (using postfix, sendmail and the like), he can get a command line (using telnet or VNC), he can perform http and database exploits with http, mysql and postgres. If he's knowledgeable, he can perform all sorts of other exploits with these services. Until your wireless network is secured, you must shut off all these (and similar) services.

stopem.sh showem.sh 
#### KILL ALL EMAIL SERVERS
/etc/init.d/fetchmail   stop
/etc/init.d/mailman   stop
/etc/init.d/postfix   stop

#### KILL ALL FILE SERVERS
/etc/init.d/nfs   stop
/etc/init.d/nfslock   stop
/etc/init.d/netfs   stop
/etc/init.d/smb   stop
/etc/init.d/winbind   stop

#### KILL WEB AND DATA SERVERS
/etc/init.d/httpd   stop
/etc/init.d/mysqld   stop
/etc/init.d/postgres   stop

#### KILL REMOTE ACCESS
/etc/init.d/vncserver   stop

#### KILL TELNET SERVERS

#### KILL MISC SERVERS
/etc/init.d/cups   stop
     
ps ax | grep fetchmail  | cut -b -76
ps ax | grep mailman    | cut -b -76
ps ax | grep postfix    | cut -b -76
ps ax | grep nfs        | cut -b -76
ps ax | grep nfslock    | cut -b -76
ps ax | grep netfs      | cut -b -76
ps ax | grep smb        | cut -b -76
ps ax | grep winbind    | cut -b -76
ps ax | grep httpd      | cut -b -76
ps ax | grep mysqld     | cut -b -76
ps ax | grep postgres   | cut -b -76
ps ax | grep vncserver  | cut -b -76
ps ax | grep cups       | cut -b -76
echo THATS ALL FOLKS
sleep 20
    You could shut them off with the S?? files in the proper boot level, or on some distros with the chkconfig program. That is the safest way to do it, assuming you do it correctly. The trouble is, there may come times when you want to alternate between having them active and having them shut down. So what I did was list the services that I felt were dangerous, making a stopem.sh script to shut them down. I then made showem.sh to verify that they were really shut down.

You might choose to make these scripts very differently. You could make a perl script to read a list of files in /etc/init.d/ with arguments like "stop", "start" and "list". Such a script would be much easier to add and subtract services, keep them in sync, etc. Me, I just did something quick and dirty.

The final question is "when will I disable this stuff?" the best answer is "as soon as practical". It must be after all the services are guaranteed to be started, but before a person logs in. I ran them out of /etc/rc.d/rc.local., appending the following to that script:

#### SLITT: STOP SERVERS FOR SECURITY
/root/stopem.sh
/root/showem.sh

I can disable the disablement by commenting out the call to stopem.sh.

You might be thinking, "I don't need to do that, I have a firewall!". Wrong!

Your firewall prevents people from coming in your Internet gateway, separating your local area network from the Internet with a strict set of rules. But it does nothing to stop a cracker with physical access to your local area network. With a wired network, this isn't a problem. If a person can come in your house and tap into your wiring, you have bigger problems than computers. How different it is with a wireless network, where any fool with a laptop can park outside and have the equivalent of a wiretap on your local area network, regardless of how carefully you protect the gateway between your LAN and the Internet.

This is why most access points have built in firewalls, password facilities, and encryption. With an encrypted access point, the guy parked outside sees only a notice of your LAN's name, and the fact that it's protected. Unless he has a good reason to be interested in you specifically, he'll drive to one of the many houses with an unprotected wireless LAN (there are loads of those).

Bottom line -- before hooking up your wireless NIC, shut down all your compromisable services, and be sure not to type any sensitive info your computer. The guy parked outside won't be able to invade your hard disk, hack your web server, or use permiscuous mode to grab your passwords. Speaking of passwords, it might be good to reset them to temporary, throwaway (but not easily guessable) passwords so if he does get them somehow, once you harden your Wi-Fi you can put back the old passwords and frustrate him further.

One last thing about the guy outside with the laptop. In Florida, at least, simply using someone else's Wi-Fi is illegal. He's subject to arrest. If you see a stranger outside with a laptop, especially before your network is hardened, call the cops. That's physical security.

Preventing a Big Hassle

A small change to a config file can render your network unusable. Therefore, before starting your wireless NIC installation, back up the /etc tree. That way, when things stop working, you can compare. Yes, things like ifcfg-ath0 or ifcfg-wlan0 should change -- that's the GUI tool doing its job. But the contents of stuff like ifcfg-eth0 or ifcfg-eth0-range0 are none of the GUI tool's business, and if they've changed, you might want to put them back the way they were.
Steve Litt is the author of Twenty Eight Tales of Troubleshooting.   Steve can be reached at his email address.

Wireless on My Compaq Presario V6133CL bcm4311, 64 Bit Mandriva

By Steve Litt
It took me 3 days to figure a quick and easy way to consistently set up wireless on my Compaq Presario V6133CL, which sports a wireless NIC with the Broadcom 4311 chipset. This works for Mandriva 2007 Powerpack X64 version, but should be at least somewhat applicable throughout the Broadcom 4311 world.

Gotchas

Unstable Video

I found the default Mandriva/Compaq video setup, and in fact almost any Linux video setup on this Compaq notebook, to be highly unstable, ESPECIALLY when switching from CLI to GUI and vice versa. About 1 in 3 times when I used Ctrl+Alt+F2 to switch to a CLI screen, the computer froze with no alternative but to power cycle.

I got around this by making sure there was no CLI anywhere -- I used a frame buffer, specifically, vga=785, which appears to give CLI sized writing, but on a frame buffer. Using frame buffers greatly decreased video instability problems.

The other thing I did was use the vesa driver instead of the nv driver or the (ugh) nvidia driver.

Need for bcm43xx-fwcutter

In every respect except one, this was a typical ndiswrapper installation. That one respect was that the bcm43xx-fwcutter program is needed to extract "firmware" and put it in the right place (in my case, /lib/firmware.). If you fail to perform that extraction, your driver will still install, and you'll still be able to use iwlist wlan0 scanning to see all nearby access points. However, association with the access point will be a hit or miss intermittent, and you will not be able to pull an IP address nor ping the other machines on the LAN, and even if somehow you manage to, it will be intermittent at best. However, once I used bcm43xx-fwcutter to install the "firmware", network access was consistent and easy.

Drivers are Hard to Find

It's hard to find the right Windows drivers for your hardware and kernel. This could be the greatest challenge. Start by downloading the drivers, for your specific notebook, from the notebook's manufacturer's site.

Match Those Bits

If you use a 64 bit Windows driver, you must use a 64 bit kernel. The only reason I chose Mandriva X86-64 over the tried and true Mandriva i586 is because the only good driver I could get, the one in Compaq's sp33008.exe driver pack, is 64 bits (contrary to Compaq's tech support).

When you see a /var/log/messages error message saying you're trying to match a 64 bit windows driver to a 32 bit kernel, you know you have a mismatch that will prevent you from getting the wireless NIC to work.

Tips

Here are some tips to make life easier.

Check Those Logs

It's often difficult to tell whether a step in the installation succeeded, and if it failed, it's always difficult to determine the failure mode. Logs help, especially /var/log/messages. I like to use a tail follower:
tail -n0 -f /var/log/messages
I look for changes after every command I perform. If relevent stuff scroll