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 scrolls off the screen, I simply review the log:
tail -n200 /var/log/messages | less
If you want your installation to go as easily as possible, check those logs.

Preliminaries

Make Sure Your Network Is Valid

Make sure you have a working network with a functioning DHCP server farming out the IP addresses of a functioning Internet gateway and a functioning DNS server. Best way to test this is to configure a known good machine with a wired connection for DHCP, down and up the network on the machine, and see if it can browse the net. Also verify that it can ping other machines on the subnet (local area network in this context). If both of those things can be done, you're probably fine.

Install Needed Packages

You'll need to install several software packages:
wireless-tools Includes iwconfig, iwlist, and other programs essential for wireless LANs. Your distro will probably have this package.
dhcp-client This is how you obtain an IP address, gateway and DNS server from a DHCP server. Includes the dhclient program. Your distro will probably have this package.
ndiswrapper A software adapter enabling a Windows driver to interface with the hardware, but acting as a translator between the Linux kernel and that Windows driver. Your distro will probably have this package.
bcm43xx-fwcutter A program to take the .sys file of a Broadcom 43xx based driver set and extract firmware. Mandriva 2007 had this package, but the program provided by Mandriva could not extract from the .sys provided by Compaq. I downloaded the latest version, performed a make;make install, and the bcm43xx-fwcutter program was placed in my /usr/local/bin directory.
cabextract A program to take the driver provided by Compaq (HP), which was provided in a .exe format, and extract the driver files. I downloaded this from the Internet, then configure;make/makeinstall to place the cabextract program into my /usr/local/bin directory.
Windows driver This is the Windows driver for your wireless LAN. Get it where you can. It must be the same number of bits as your kernel, and must be compliant with bcm43xx-fwcutter. If you're lucky enough to have a driver CD, start there. Otherwise, if you have a notebook or preassbled desktop (Dell, Compaq, etc) start at the computer vendor's website download area. If you bought the wireless LAN device separately, start at the website of the device's manufacturer. When I downloaded my driver, it was from the HP website (HP now owns Compaq), as sp33008.exe.

When you've installed wireless-tools, dhcp-client, ndiswrapper, bcm43xx-fwcutter, cabextract, and you've downloaded or otherwise obtained the Windows drivers, continue on...

The Procedure

Do this whole thing, logged in as root, without X running. You don't need any complications. As far as I know, none of this depends on distro specific tools, and you do the whole thing from the command prompt. Therefore, it's easy and reproducible, and has few or no side effects.

cd
    Get to the /root directory.
mkdir driver
A place for the driver to go.
cd driver
Go there.
cabextract /whatever/sp33008.exe
Extract driver files into the /root/driver, including files bcmwl5.inf and bcmwl5.sys.
bcm43xx-fwcutter -w /lib/firmware bcmwl5.sys
Extracts "firmware" files out of bcmwl5.sys and into /lib/firmware, where the ndiswrapper module can use them.
rm /etc/modprobe.d/ndiswrapper
So that reboot won't start ndiswrapper. This begins a series of steps to remove any former ndiswrapper installation.
vim /etc/modprobe.conf
Delete any lines associating wlan0, wlan1, etc to ndiswrapper.
rmmod ndiswrapper
Remove any existing ndiswrapper module.
lsmod | grep ndis
Test for removal. If removal wasn't successful, reboot and test again. Do not continue until no ndiswrapper module is loaded.
ndiswrapper -l
List loaded ndiswrapper-assisted drivers.
ndiswrapper -e bcmwl5
Delete any existing bcmwl5 driver from ndiswrapper.
ndiswrapper -l
Be sure it's deleted. This concludes the series of steps to eliminate any former ndiswrapper installation.
ndiswrapper -i bcmwl5.inf
Associate the Windows driver with ndiswrapper. What this really does is copy files to another place on your hard disk.
ndiswrapper -l
Make sure it worked. The reply should be "driver installed, hardware present". If not, troubleshoot.
ndiswrapper -m
Makes the driver load on boot. What this really does is put the string "alias wlan0 ndiswrapper" either in a newly created file called /etc/modprobe.d/ndiswrapper, or in /etc/modprobe.conf.
depmod -a
Correct all module dependencies.
tail -n0 -f /var/log messages
Do this in another terminal (or Ctrl+Alt+F2) to enable you to see messages when you load the module.
modprobe ndiswrapper
Do this in the original terminal, and then view the results in the log tail. You should see evidence of the driver having loaded. However, you'll almost certainly see something saying you have no link. That's normal -- indeed you have no link because you've not yet associated to an access point. If you see other major errors, you might want to investigate.
lsmod | grep ndis
Check whether it loaded. If it didn't load, you have problems. If it did load, and if the log tail showed no major problems, you're probably OK.
iwlist wlan0 scanning
This scans for all nearby access points, no matter their encryption. If they're set to broadcast their essid, they'll show up on the list. If you get an error message, your driver isn't installed correctly. If you get nothing on your list, either no nearby access points are broadcasting their essid, or the driver's not installed correctly. Even if you get a list of access points, it's possible the driver still isn't installed correctly, but the fact that you see a list of access points (possibly with only one access point listed) is a very good sign.

Danger Will Robinson!!!

The iwlist command may fail if you booted your computer with a wired network card plugged into the network. That happened to me, and if I hadn't done this installation so many times, it might have led me on a wild goose chase. As it was, I simply remembered what I'd done differently in the last install, unplugged the Cat45 cable from the wired network card, rebooted, and iwlist suddenly worked.

Don't get snookered by this anomoley. If iwlist doesn't work, unplug cable from the wired network card and run it again. If it still doesn't work, reboot with the cable disconnected.

As far as I know, once you've succeeded in getting iwlist, you can leave the network cable plugged into the wired NIC.

The preceding looks like a lot, but it can be done in 10 to 15 minutes, probably with success and few or no side effects. In the long run, this is probably much faster than the tools your distro gave you.

Finishing the Job With Scripts

If you can scan, let's presume your driver is installed correctly. If so, you can write a simple script to get it to connect. First, check your ifcfg-wlan0 file. It should be very simple, something like this:
DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes

Because your script will take care of everything else the wireless network card needs to know, the preceding is sufficient. Anything else is superfluous and will complicate your troubleshooting.

The Script to Connect to a Wep Encrypted Access Point

Here is the script to connect to a WEP encrypted access point:
#!/bin/bash
iwconfig wlan0 key [1] <hex key 1>
iwconfig wlan0 key [2] <hex key 2>
iwconfig wlan0 key [3] <hex key 3>
iwconfig wlan0 key [4] <hex key 4>
iwconfig wlan0 key [1]
iwconfig wlan0 mode Managed
iwconfig wlan0 essid <essid of your access point>

Note the final key statement says which of the four keys to use, and it could
as easily be 2, 3 or 4. Make sure you ALWAYS put the essid statement last -- according to the comments in /etc/sysconfig/network-scripts/ifup-wireless, it might not work otherwise. As far as the four hex keys, copy them right off the webapp for the access point.

Before running the preceding script, the iwconfig command should show that your wireless NIC is not associated with any access point. After running the script, if the hex keys and access point essid are correct, the iwconfig command should say you're associated with the chosen essid, and should give a non-zero access point hardware address. At this point you're associated.

If the LAN's DHCP server is configured correctly, running the preceding script should probably also give wlan0 an IP address, gateway and DNS such that you can surf the net. If not, try ifdown wlan0;ifup wlan. If still no joy, try this and look at the logs while doing it:
dhclient wlan0
If you see errors in the log, troubleshoot accordingly. If you don't get an IP address, try tweaking /etc/sysconfig/network-scripts/ifcfg-wlan0 with BOOTPROTO=static, and the IP address, gateway and netmask compatible with the LAN. Here's an example:

DEVICE=wlan0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.100.2
NETMASK=255.255.255.0
BROADCAST=192.168.100.255
GATEWAY=192.168.100.96

Last but not least, put the address of your DNS server in /etc/resolv.conf.

Restart your network with /etc/init.d/network restart or whatever the command is on your distro, run your script again, and see whether you can browse the net. If so, there was something wrong with the DHCP configuration, probably on your network. If not, there's an esoteric problem -- troubleshoot.

The Script to Connect to an Unencrypted Access Point

Here is the script to connect to an Unencrypted access point:
#!/bin/bash
iwconfig wlan0 mode Managed
iwconfig wlan0 essid any

The preceding should associate with the strongest unencrypted access point. If for some reason it doesn't associate, or if you want to associate with a specific access point, use the following script with the desired essid as its argument:

#!/bin/bash
iwconfig wlan0 mode Managed
iwconfig wlan0 essid $1

If the script is called associate.sh, you invoke it like this:
associate.sh <essid of desired access point>
To see a list of possible essids, perform iwlist wlan0 scanning. It will show you a list of access points, listing their encryption status, and their signal level as a negative number. Lesser negative numbers are stronger, so -18 is stronger than -50. Pick the strongest unencrypted access point to which you have a right to connect, and use its essid as the argument to your script.

Before running the preceding script, the iwconfig command will likely show that your wireless NIC is not associated with any access point. After running the script, if the hex keys and access point essid are correct, the iwconfig command should say you're associated with the chosen essid, and should give a non-zero access point hardware address. At this point you're associated.

If the LAN's DHCP server is configured correctly, running the preceding script should probably also give wlan0 an IP address, gateway and DNS such that you can surf the net. If not, try this and look at the logs while doing it:
dhclient wlan0
If you see errors in the log, troubleshoot accordingly. If you don't get an IP address, try tweaking /etc/sysconfig/network-scripts/ifcfg-wlan0 with BOOTPROTO=static, and the IP address, gateway and netmask compatible with the LAN. Here's an example:

DEVICE=wlan0
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.100.2
NETMASK=255.255.255.0
BROADCAST=192.168.100.255
GATEWAY=192.168.100.96

Last but not least, put the address of your DNS server in /etc/resolv.conf.

Restart your network with /etc/init.d/network restart or whatever the command is on your distro, run your script again, and see whether you can browse the net. If so, there was something wrong with the DHCP configuration, probably on your network. If not, there's an esoteric problem -- troubleshoot.

If Intermittent or Wierd, Check Firmware!

Yesterday I spent about four hours troubleshooting a situation where the driver appeared to be properly installed, in that the iwlist wlan0 scanning command found the access point, but the script rarely caused association, and association sometimes happened all by itself (or minutes or hours after the last running of the script), and no matter what, I could not ping anything on the subnet. It had my tearing my hair out, so I put it aside and went to sleep.

When I woke up this morning I remembered that, as an experiment, I had declined to put the firmware in /lib/firmware. I backed out the wlan0 installation, redid it including the firmware, and it worked perfectly.

If you have wierd, intermittent problems with your Broadcom 4311 based wireless NIC, with iwlist doing the right thing but seldom being able to associate and seldom or never being able to ping, check that you installed the firmware.

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 Linksys WUSB54G, 32 Bit Mandriva

By Steve Litt
After spending over a day getting my Compaq's built in Broadcom bcm4311 working with 64 bit Mandriva, I discovered that my 64 bit Mandriva install DVD didn't come with LyX, or any of the stuff you need to build LyX.

NOTE:

This may not be Mandriva's fault. My copy of Mandriva came from LinuxCentral.Com, not from Mandriva themselves. Therefore, there's no way for me to know (without extensive research) whether LyX was left out of 64 bit Mandriva 2007, or whether LinuxCentral packaged it wrong.

Can you imagine me without LyX? No course instructor notes. No Ebooks. No books of any kind. In other words, no business. I don't know what happened to LyX, when it's been in every Mandrake since 6x (or before), whether procured from MandrakeSoft or from repackagers such as CheapBytes and LinuxCentral. Ugh!

So I had to zap my 64 bit Mandriva and lay down (the slower) 32 bit. And of course, the 64 bit Windows driver for this machine didn't work with a 32 bit kernel. What a whoopie cushion!

Luckily, my external USB wireless NIC, a Linksys WUSB54G, came with a CD containing a 32 bit driver. It turned out to be relatively simple:
ndiswrapper -i rt2500usb.inf
ndiswrapper -l
ndiswrapper -m
depmod -a
tail -fn0 /var/log/messages
modprobe ndiswrapper
iwlist wlan0 scanning
iwconfig wlan0 mode Managed
iwconfig wlan0 essid any
ifdown wlan0
ifup wlan0
ping troubleshooters.com
A couple notes -- those steps were how I remember them -- I was way too rushed to carefully document. Also, obviously the tail -nf0 command was done in a different terminal than the other commands so I could see error and success messages after performing the modprobe command. Further, I didn't have to back out a previous ndiswrapper installation, which is one reason why the preceding might seem significantly simpler than the equivalent Broadcom/Mandriva 2007-32 installation. The other reason this seems simpler is because no firmware extraction was necessary.

However, I was required to blacklist the native Linux driver, placing the following in /etc/modprobe.d/blacklist:
blacklist rt2570
Boy I love ndiswrapper!
Steve Litt has been writing Troubleshooting Professional Magazine for ten years. Steve can be reached at his email address.

Native Linux Linksys WUSB54Gv4 (Ralink rt2570) on 32 Bit Mandriva Desktop

By Steve Litt
The preceding article discussed using ndiswrapper with the Linksys WUSB54G version 4. This article discusses using the native Linux driver that comes with the distro (/lib/modules/2.6.17-5mdv/kernel/3rdparty/rt2570/rt2570.ko.gz, which is in the kernel-2.6.17.5mdv package).

Here are two ways to do it:
  1. Command line only
  2. Partial distro tool use
If possible, I recommend the command line only method. However, if you can't get the command line only method to work, try using the distro tools.

Command line only

Here's the basic procedure, all of which should be done as root:
  1. In one terminal, tail -fn0 /var/log/messages
  2. Plug in the WUSB54G version 4 wireless NIC
  3. Note the "tweaked" driver name referenced in /var/log/messages
  4. Find the "true" driver name with lsmod | grep usbcore
  5. Create a simple /etc/sysconfig/network-scripts/ifcfg-rausb0
  6. echo alias rausb0 rtusb >> /etc/modprobe.conf
  7. Reboot the computer
  8. Try iwlist rausb0 scanning
    1. If necessary, try one or more ifdown rausb0 and ifup rausb0
  9. Back up /etc/modprobe.conf
  10. Associate by whatever means appropriate

In one terminal, tail -fn0 /var/log/messages

You'll see the messages occurring when you plug in the USB wireless NIC, and luckily for you, those messages will contain both the (tweaked) driver name and the interface name.

Plug in the WUSB54G version 4 wireless NIC

Mandriva 2007 is set up so that when you plug in a USB device, it executes code to enable the device you plug in. The executed code writes to the log.

Note the "tweaked" driver name referenced in /var/log/messages

The log file output will look something like this. Note the (tweaked) device name and the device name, both highlighted in dark red in the log output below:

Dec 11 14:41:01 localhost kernel: usb 4-5: new high speed USB device using ehci_hcd and address 2
Dec 11 14:41:01 localhost kernel: usb 4-5: configuration #1 chosen from 1 choice
Dec 11 14:41:01 localhost kernel: idVendor = 0x13b1, idProduct = 0xd
Dec 11 14:41:01 localhost kernel: usbcore: registered new driver rtusb
Dec 11 14:41:02 localhost udevd-event[6203]: rename_netif: error changing netif name rausb0 to : Invalid argument

So now you know the device name is rausb0 and the (tweaked) device name is rtusb. I say tweaked because the driver, as listed in the lsmod command, is rt2570, not rtusb., and is contained in file /lib/modules/2.6.17-5mdv/kernel/3rdparty/rt2570/rt2570.ko.gz. The following commands show that the rtusb and rausb0 identifiers are contained in the rt2570 driver:
zless /lib/modules/2.6.17-5mdv/kernel/3rdparty/rt2570/rt2570.ko.gz | strings |  grep rtusb
zless /lib/modules/2.6.17-5mdv/kernel/3rdparty/rt2570/rt2570.ko.gz | strings | grep rausb
When the rt2570 driver starts, it makes another "driver" called rtusb, associated with rausb0.

Find the "true" driver name with lsmod | grep usbcore

[root@localhost ~]# lsmod | grep usbcore
usbcore 113472 4 rt2570,ehci_hcd,uhci_hcd
[root@localhost ~]#

Armed with the device name, "tweaked" driver name and "real" driver name, you can do the rest of the job.

Create a simple /etc/sysconfig/network-scripts/ifcfg-rausb0

It should look approximately like this:

DEVICE=rausb0
BOOTPROTO=dhcp
ONBOOT=yes

Existence of that file enables things like ifup rausb0.

echo alias rausb0 rtusb >> /etc/modprobe.conf

By placing the string alias rausb0 rtusb in the /etc/modprobe.conf file, you ensure that on reboot the rt2570 driver is loaded correctly, and at the right time. This maximizes the likelihood of success, and also minimizes the likelihood that using ifdown or pulling out the USB plug will freeze the computer (that can happen).

Reboot the Computer

Yes, you can probably get the device working without rebooting, but it takes a whole lot more experimentation and just plain fooling around. By rebooting, you start with a clean slate and because of the line in modprobe.conf, you know the driver will be loaded at the right time.

I said the driver will be loaded, I did not say it would associate. You'll probably get a failed message for rausb0 on boot. Don't worry, that's just a problem with not associating.

Try iwlist rausb0 scanning

Try this command:
iwlist rausb0 scanning
It should list nearby access points. If it doesn't, try some ifdown , ifdown, and maybe /etc/init.d/network restart  commands. Fool around with it until you can get an access point list. If you really have problems, look at/var/log/messages.

Associate by whatever means appropriate

As mentioned many times in this document, a correctly installed driver that procures an access point list does not mean you can associate. Write a script to issue iwconfig commands necessary to associate with open or encrypted access points, as appropriate.

Partial distro tool use

I recommend the command line method, but if you can't get it to work, your distro tools might work. In Mandriva 2007, run drakconf and do the following:
  1. Click the "Network & Internet" tab
  2. Click the "Set up a new network interface" icon or link
  3. Choose "Wireless" from the list
  4. Click the "Cisco-Linksys|Wireless-G USB Network Adaptor" radio button and click the Next button
  5. Fill in the rest of the prompts as appropriate
  6. DO NOT click the "Wireless connection" icon or link. This tool writes so many files and has so many side effects that you might never again achieve a known state.
  7. Exit drakconf
  8. iwlist rausb0 scanning
  9. Associate as appropriate
Note that the distro tool writes a big, hairy /etc/sysconfig/network-scripts/ifcfg-rausb0. Unfortunately, some of the lines of that file might prevent correct driver loading, scanning or association. My experience is that you're better off commenting out everything but this:

DEVICE=rausb0
BOOTPROTO=dhcp
ONBOOT=yes

Later, you can uncomment some of the lines, possibly eliminating the need for iwconfig scripts.

Once again, in my opinion, the command line option is better because you're in complete control and retain a known state. However, sometimes the command line method requires more knowledge than you have at the moment, in which case the distro tools might be your best bet.
Steve Litt is the author of Twenty Eight Tales of Troubleshooting.   Steve can be reached at his email address.

Using WPA

By Steve Litt
You might wonder why I saved this article for last. Here's why -- WPA is a bear!!!!!

Unlike WEP or Open, you can't use scripts to get associated -- you must use /etc/wpa_supplicant.conf and /etc/sysconfig/network-scripts/ifcfg-whatever.

Let's start with the obvious. In Linux, the only way to connect to a WPA encrypted access point is using the wpa_supplicant tool, so you must install that tool. Most Linux distros include that tool in their distribution, so it shouldn't be hard.

The next thing you need to do is get the driver installed. In other words, iwlist myinterface scanning should produce a list of nearby access points. Once you have that, it's time to tweak /etc/wpa_supplicant.conf and /etc/sysconfig/network-scripts/ifcfg-whatever. This article uses a desktop with Mandriva 2007 32bit using an ndiswrapper driver. Therefore the device in question is wlan0.

The following should go at the bottom of /etc/wpa_supplicant.conf:
network={
key_mgmt=NONE
scan_ssid=1
ssid="any"
}

network={
psk="mypassphrase"
scan_ssid=1
ssid="myssid"
}

In the preceding, mypassphrase is the passphrase from the access point's wireless security section. The myssid is simply the essid of the access point. That's half the battle. The other half is your /etc/sysconfig/network-scripts/ifcfg-whatever. My /etc/sysconfig/network-scripts/ifcfg-wlan0. looks like this:

DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes
WIRELESS_ENC_KEY="open s:mypassphrase"
WIRELESS_WPA_DRIVER=wext
DHCP_CLIENT=dhclient

The preceding is where the rubber meets the road. With WPA encryption you have a catch 22. You can't get a link until you associate, and you can't associate until you get a link. That's why, with WPA encryption, it's difficult or impossible to do it with scripts. Instead, your /etc/sysconfig/network-scripts/ifcfg-whatever actually runs wpa_supplicant., in my case using the wext (generic Linux) driver, with the access point's encryption passphrase.

DANGER WILL ROBINSON!

Notice WIRELESS_WPA_DRIVER=wext. If you read the text on wpa_supplicant --help, you'll see an option -D<drivername>, where <drivername> can be one of the following:

  • hostap = Host AP driver (Intersil Prism2/2.5/3)
  • prism54 = Prism54.org driver (Intersil Prism GT/Duette/Indigo)
  • madwifi = MADWIFI 802.11 support (Atheros, etc.)
  • atmel = ATMEL AT76C5XXx (USB, PCMCIA)
  • wext = Linux wireless extensions (generic)
  • ndiswrapper = Linux ndiswrapper
  • ipw = Intel ipw2100/2200 driver
The implication is we should have used  WIRELESS_WPA_DRIVER=ndiswrapper, but that errors out like this:

The only way to fix it is WIRELESS_WPA_DRIVER=wext.

I tried and failed to get this same configuration working with the Linux native rt2570/rtusb driver, but it errored out with several "operation not permitted". Perhaps you'll do better. If you try, I have this word of encouragement: "good luck with that!". Let me quote out of the Rt2x00Wiki FAQ at http://rt2x00.serialmonkey.com/wiki/index.php?title=FAQ:

Q. How can I get the wpa_supplicant to work with RT2400, RT2500 or RT2570?
A. wpa_supplicant is not supported for the old RT2400, RT2500 or RT2570 modules.
RT2400 only supports WEP, while RT2500 and RT2570 support WEP & WPA. All encryption is handled by the driver itself.

Huh? No wpa_supplicant? Turns out you need to use iwpriv to set AuthMode, EncrypType, and WPAPSK, and supposedly it will magically receive WPA. So I hunted down this script from the "Mandrake 10 rt2570 Howto" at http://rt2x00.serialmonkey.com/wiki/index.php/Mandrake_10_rt2570_Howto:

#!/bin/bash
iwpriv rausb0 enc 3
iwpriv rausb0 auth 3
iwconfig rausb0 essid "your wireless network name"
sleep 1
iwpriv rausb0 wpapsk "your top secret password"
sleep 1
iwconfig rausb0 essid "your wireless network name"

No joy. DHCP, or static with hardwired IP address, you cannot ping other machines on the subnet. If you figure out how to get rt2570 to do WPA/PSK and can describe it exactly, please email me.

In the meantime, I'll repeat what I've said frequently in this document. Native Linux drivers are not necessarily better than ndiswrapper adapted drivers. And all ndiswrapper installations resemble each other, so you're not doing something brand new every time you install a different wireless NIC.

WPA Troubleshooting

If you're anything like me, you won't associate with a WPA encrypted access point the first time. Or the second. Maybe not even the tenth. It's not easy. Some drivers don't support it at all, some support it in nonstandard ways (such as rt2570, which does it directly instead of through wpa_supplicant). Most drivers have lousy documentation. Most drivers are very different in their configuration and behavior.

The first thing to do is check for ability to scan:
iwlist mydevice scanning
where mydevice is ath0, wlan0, rausb0, etc. If it doesn't show at least one nearby access point, either you have no working access points, or your driver isn't installed correctly. Either way, you're not yet at the stage where you can even try to associate.

You might see the dreaded "no link present" message:

[root@fester ~]# ifup wlan0

Determining IP information for wlan0... failed; no link present. Check cable?
[root@fester ~]#

The preceding message can be caused by several things, but when dealing with WPA, a bad wpa_supplicant driver option (the -D parameter) is often the cause, and please remember, it should be wext for ndiswrapper drivers, at least with the Ralink rt25 series. So, before trying the ifup command again, in a separate root terminal run the following command:
wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0 -D wext
THEN try the ifup wlan0 command, and see if things now work correctly. If so, adjust your /etc/sysconfig/network-scripts/ifcfg-wlan0 (or whatever for your device) so it's unnecessary to manually run wpa_supplicant.

Remember, to associate with a WPA encrypted access point, wpa_supplicant must be running before the ifup command is given. Also be aware that the ifdown wlan0 command kills that wpa_supplicant command.

DANGER WILL ROBINSON!

The ifdown command kills any wpa_supplicant program running for the same device. For instance, if you:
wpa_supplicant -c /etc/wpa_supplicant.conf -i wlan0 -D wext
ifup wlan0
ping troubleshooters.com
ifdown wlan0
ifup wlan0
ping troubleshooters.com
The second ping won't work because the ifdown command terminated the wpa_supplicant program. If you're not aware of this or forget it, this creates some very difficult troubleshooting issues as it appears that ifup is intermittent. What makes this even more difficult is that wpa_supplicant is usually run as a daemon (using the -B option), so you don't see it being killed by the ifdown command.

When using WPA or WPA2, always make sure there's a running wpa_supplicant before running ifup.


Look in the log (tail -fn0 /var/log/messages) and see what it says concerning "link beat not present" or "link beat detected" or whatever. The "link beat not present" message means you can't associate, at least unless the link beat is detected later in the process.

Another diagnostic test is to switch the access point to no encryption, and see if you can associate. If not (when following the proper techniques described earlier in this document), one possible cause is another driver is coming in and elbowing out the driver you're trying to run. As an example, if you're trying to use ndiswrapper with the rt2500usb.inf Windows driver and it just isn't working, perhaps the native driver (rt2570/rtusb/rausb0) is shoving it aside. To determine that, /var/log/messages or dmesg is your friend. If it's that type of situation, you need to blacklist the native driver by inserting the following in /etc/modprobe.d/blacklist:
blacklist rt2570
blacklist rtusb
Then reboot and see if the problem disappears. If not, there are probably other references to the old driver. Look for any such references with these three commands:
cd /etc
find . | grep rt25
find . | grep rtusb
find . | grep rausb
If you find such references, comment them out or delete them. It's a good idea to back up the original file, just in case. Then reboot again.

Other Drivers

I got my Acer Aspire 5100 to associate with a WPA accesspoint. I let Mandriva's GUI distro specific tools do it for me (bad Steve). Here are the relevant files:
wpa_supplicant.conf
relevent code

ifcfg-ath0
network={
key_mgmt=NONE
scan_ssid=1
ssid="any"
}

network={
psk="mypassphrase"
scan_ssid=1
ssid="myssid"
}
DEVICE=ath0
BOOTPROTO=dhcp
ONBOOT=yes
METRIC=35
MII_NOT_SUPPORTED=no
USERCTL=no
RESOLV_MODS=no
WIRELESS_MODE=Roaming
WIRELESS_ENC_KEY="open s:mypassphrase"
WIRELESS_WPA_DRIVER=madwifi
IPV6INIT=no
IPV6TO4INIT=no
DHCP_CLIENT=dhclient
NEEDHOSTNAME=yes
PEERDNS=yes
PEERYP=yes
PEERNTPD=no

In the preceding ifcfg-ath0, most of the extra code is extraneous. However, note that WIRELESS_WPA_DRIVER=madwifi. The madwifi driver is specific to Atheros chipsets, which is what the Acer has. Bottom line -- between native and ndiswrapper drivers, plus the ability to plug in external wireless NICs, you have an excellent chance of implementing WPA, given enough desire.

About WPA2

This document says nothing about WPA2 encryption. That's because I ran out of time. I'm pretty sure that if the driver supports wpa2, it won't be hard to do. However, this has been the hardest Linux Productivity Magazine I've ever written, I'm tired, and at least for now I'm not going to document WPA2.

Summary

WPA encryption is difficult, to say the least. Even more variables than normal, difficult troubleshooting, what a mess! There's only one reason to do it -- WPA (and WPA2) is much more secure than WEP, and lightyears more secure than an open access point.

To use WPA, the device and drive must both be WPA capable. If the device is WPA capable, the manufacturer almost certainly made a WPA capable Windows driver, in which case it's very likely that such a driver interfacing with ndiswrapper will be WPA capable.

The simplest WPA/PSK (personal WPA) wpa_supplicant.conf code looks like this:

network={
key_mgmt=NONE
scan_ssid=1
ssid="any"
}

network={
psk="mypassphrase"
scan_ssid=1
ssid="myssid"
}

The simplest WPA/PSK (personal WPA) Mandriva based /etc/sysconfig/network-scripts/ifcfg-wlan0. looks like this:

DEVICE=wlan0
BOOTPROTO=dhcp
ONBOOT=yes
WIRELESS_ENC_KEY="open s:mypassphrase"
WIRELESS_WPA_DRIVER=wext
DHCP_CLIENT=dhclient

On my system, the preceding two files enabled my WPA encrypted access point to be associated immediately upon boot. Remember, on my system the driver needed to be wext, not the more intuitive ndiswrapper.

If for some reason the preceding ifcfg-wlan0 doesn't work, you can also do it manually as follows:
ifdown wlan0
wpa_supplicant -B -c /etc/wpa_supplicant.conf -i wlan0 -D wext
ifup wlan0
In the preceding the -B option makes it a backround daemon. Always remember that doing it manually you must run wpa_supplicant before ifup. Also remember that ifdown kills the running wpa_supplicant, and that's hard to see and remember if that wpa_supplicant is a daemon, especially if it was started automatically by booting a correctly configured system or by using the GUI connection tool.

When troubleshooting, first make sure that iwlist mydevice scanning gives an accesspoint list. If not, that's what needs to be troubleshot.

In the case of a "no link present" message, make sure you're using the correct wpa_supplicant driver, whether in the wpa_supplicant command, or as the WIRELESS_WPA_DRIVER line in ifcfg-mydevice. If you can't associate even with no encryption (when following the proper techniques described earlier in this document), consider the possibility that another driver is butting in, and if so blacklist that driver.

I haven't described the technique to associate with WPA2 in this document because I ran out of time, but I suspect if you can associate to WPA and if the device and driver support WPA2, it should be fairly simple. Although this article describes associating with a WPA encrypted access point using the ndiswrapper linked rt2500usb.inf Windows driver, between ndiswrapper and native drivers, and access to external wireless NICs, you stand a good chance of associating with WPA using Linux.
By Steve Litt Steve Litt is the author of many books. Steve can be reached at his email address.

Part III: Editorials

Thank You

By Steve Litt
A huge thank you to those who have programmed drivers for wireless network cards. It's a difficult job, and probably thankless. Without card specifications there's no way writing drivers is easy. Also thanks to my old friend, Mark Matthews of the WLAN project, who gave me help and encouragement. Thanks to another old friend, Noel Henson, who talked me down from an attitude violation when, with one day til I had to take the laptop on the road, he suggested several alternatives in case I couldn't get this silly Broadcom bcm4311 working with 32 bit Mandriva (I couldn't, and went on the road toting my Linksys WUSB54G usb wireless NIC.

Thanks to Atheros, a wireless NIC maker, who from my experience and my reading steadfastly supports Linux and its community. Getting my Atheros wireless NIC working on Mandriva 2007 on my Acer Aspire 5100 was a 10 minute simplicity -- the only native Linux driver I've ever gotten to be stable. Unfortunately, the Acer as a whole wasn't stable enough to take on the road.
Steve Litt is the author of Twenty Eight Tales of Troubleshooting.   Steve can be reached at his email address.

Villains Abound!

By Steve Litt
I'm mad. Furious. Livid. I spent weeks getting Wi-Fi to work on two different laptops and several different Wi-Fi devices. The Windows guy would have spent an hour. Whose fault is this?

Obviously it's Bill Gates' fault. With the help of his sidekick Stevie, he's deliberately created an illegal monopoly (even the appeals court said it was an illegal monopoly as they sent it back for a new penalty phase, but the newly elected administration's justice department let Microsoft off with the gentlest wrist slap. So now Microsoft continues to make everything incompatible, and many of their standards secret.

But Bill Gates has had lots of help.

Consider the hardware manufacturers. Most have the attitude "if you use Linux, you're on your own." Many refuse to release specifications or APIs, and of course Linux drivers.

All of this could be overcome with strong intra-community advice and documentation, and a strong dose of ndiswrapper. But our community has failed us with all sorts of incomplete, conflicting documentation, most of which is barebones and applies only to the writers specific setup.

NOTE

Yes, I know the preceding sentence also describes this document, but at least I've run and rerun experiments to make sure my results weren't just dumb luck, and in doing so I think this document gives you a much higher chance of success than most other documentation on this subject.

And speaking of ndiswrapper, how about all these Linux chauvinists declaring that native drivers are always more stable and "better". How many people give up after receiving such advice when they can't get get alpha test level native drivers to work?

Our community has its share of trolls, phony intellectuals, holier than thou RTFM types, inflexible free software purists, and guys refusing to support businesses because they believe businesses don't "give back to the community". There's a special place in the land of fire and brimstone for these guys. They're discussed in this month's Life After Windows column.

Of course, maybe the "they don't give back" guys have a point. Google any wireless error message, and you'll get at least 100 posts asking about it for every one who, after solving, bothered to post the solution with <SOLVED> in the subject.
Steve Litt's business, Troubleshooters.Com, has run off Linux since March 2001. Steve can be reached at his email address.

Life After Windows: Take Your Hand Off of My Wallet, Troll!

Life After Windows is a regular Linux Productivity Magazine column, by Steve Litt, bringing you observations and tips subsequent to Troubleshooters.Com's Windows to Linux conversion.
I subscribe to many LUG mailing lists. On one of them (I don't remember which one), someone said something to the effect that businesses use Linux without contributing back, implying that the free software community shouldn't bother supporting such businesses.

Remembering all the trouble I had getting Wi-Fi to work on my Linux Laptop, I wrote back saying business recruited new people to Linux, making it more likely that hardware manufactures would support Linux through either drivers or specifications, leading to more and better Linux drivers. Other people responded the same way, but the guy saying "don't bother" remained adement.

I might have lost interest in the thread if my new laptop hadn't broken (hardware problem -- intermittently wouldn't POST -- wouldn't count memory). I had to spend a thousand dollars for a new laptop to replace it. At this point it's unclear what will become of the old (3 weeks old) one.

Anyway, I spent $1000.00 at Costco for a Compaq Presario V6133CL, which turned out to have a much less Linux-friendly wireless NIC -- a Broadcom as opposed to the broken Acer's Linux friendly Atheros. I spent days getting the wireless to work, trying various Mandriva versions before getting the right combination of functionality and applications. I'd estimate the cost in my time to be well over a thousand dollars.

Windows guys never have to put up with this. Every box they buy works immediately. How different it is with Linux, where we have only 10% market penetration (if that). We must blow off the Windows operating system we paid for. We must search for drivers, experiment and troubleshoot. We must find known Linux-compatible computers, or else shop where they have an extremely permissive guarantee (Costco said if Linux didn't work, I could return it!), or else pay for something we can't use. All because of our pitiful market share.

And there's this guy talking about how we shouldn't bother with businesses because they don't "contribute back". I was livid! This guy's attitude was a sure way to shut Linux out of the business community, therefore preventing its spread throughout the marketplace, thereby removing any pressure for hardware vendors to make their equipment Linux compatible with good Linux drivers, thereby taking money right out of my pocket.

I almost shot back, but I don't like flame wars and so held my tongue (my finger, actually). And really, this particular guy had done nothing that cost me money. The sum and total of people who think like him cost me (and all others using Linux for business), but that individual guy wasn't responsible for my problems.

Think of all the other types who prevent business adoption. Trolls responding to simple statements with emotional craziness. Phony intellectuals responding to a question of "where's the shovel" with a ten page treatise on features of various shovels, and their development history. Would-be "tough love" guys yelling "RTFM" or pointing the asker to Eric Raymond and Rick Moen's "How To Ask Questions The Smart Way" essay. I agree with about 90% of Raymond and Moen's essay, but responding to a specific help request with a link to that essay is very insulting, and often not deserved.

Then there are the inflexible free software purists, to whom nothing but totally copylefted licenses are adequate, even if they do prevent businesses from using them in software they distribute, such as drivers. They often prevent usage by business because, to stay in license compliance, the business would need to provide source for any of their trade secret software that is linked to the copylefted software that gets distributed, such as a driver. With fully copylefted license, such as the GPL version 2, there's no exception to make 95% GPL, but the code interfacing with their trade secrets private.

What business in their right mind would reveal their trade secrets to comply with a license? I personally use the GNU GPL as my default license, but that doesn't mean it, or strongly copylefted licenses like it, are right for every business need. Sometimes a permissive license like the BSD license is what the business needs (or else they'll just go proprietary, and, as explained earlier, that's money out of our pockets).

Have you noticed the name of this magazine? Linux Productivity Magazine. Not Linux Hobbiest Magazine, nor Linux Hacker Magazine, nor Linux Poser Magazine. It's written for people who use Linux to perform needed tasks. Have you noticed that a lot of the flamers, trolls, phony intellectuals, "tough love" guys and inflexible free software purists don't run businesses on Linux? How many of them dabble in Linux? Not all of them -- Richard Stallman wrote Emacs and is responsible for gcc, making him an almost peerless contributor. But I have a feeling that for each Richard Stallman, there are ten trash talkers who just want to ram their viewpoints down people's throats. When that happens, business bolts, and when that happens, it makes it more expensive for guys like us to get Wi-Fi working and buy notebook computers that work with Linux.

Businesses contribute alright -- they recruit new Linux users, which creates more developers, and creates a marketplace where hardware vendors can no longer ignore us.

And one other thing -- who said businesses don't contribute. I may be a simple Troubleshooting Process Instructor and Book Author, but I originated the VimOutliner project, which now has quite a large following, is probably the most used outliner in Linux, and has been ported to Windows and is now used there. I also created UMENU, which while not as successful, is used by several people (including the US government, from what I understand). Businesses often contribute source code.

Tell the trolls, flamers, tough love screamers, inflexible free software purists, phony intellectuals, and those yelling "we don't help those who don't contribute" to keep their hands off your wallet. Let them know, offlist, how badly they're hurting Linux, and therefore, how much they're costing you.
Steve Litt is the founder and acting president of Greater Orlando Linux User Group (GoLUG).   Steve can be reached at his email address.

GNU/Linux, open source and free software

By Steve Litt
Linux is a kernel. The operating system often described as "Linux" is that kernel combined with software from many different sources. One of the most prominent, and oldest of those sources, is the GNU project.

"GNU/Linux" is probably the most accurate moniker one can give to this operating system. Please be aware that in all of Troubleshooters.Com, when I say "Linux" I really mean "GNU/Linux". I completely believe that without the GNU project, without the GNU Manifesto and the GNU/GPL license it spawned, the operating system the press calls "Linux" never would have happened.

I'm part of the press and there are times when it's easier to say "Linux" than explain to certain audiences that "GNU/Linux" is the same as what the press calls "Linux". So I abbreviate. Additionally, I abbreviate in the same way one might abbreviate the name of a multi-partner law firm. But make no mistake about it. In any article in Troubleshooting Professional Magazine, in the whole of Troubleshooters.Com, and even in the technical books I write, when I say "Linux", I mean "GNU/Linux".

There are those who think FSF is making too big a deal of this. Nothing could be farther from the truth. The GNU General Public License, combined with Richard Stallman's GNU Manifesto and the resulting GNU-GPL License, are the only reason we can enjoy this wonderful alternative to proprietary operating systems, and the only reason proprietary operating systems aren't even more flaky than they are now. 

For practical purposes, the license requirements of "free software" and "open source" are almost identical. Generally speaking, a license that complies with one complies with the other. The difference between these two is a difference in philosophy. The "free software" crowd believes the most important aspect is freedom. The "open source" crowd believes the most important aspect is the practical marketplace advantage that freedom produces.

I think they're both right. I wouldn't use the software without the freedom guaranteeing me the right to improve the software, and the guarantee that my improvements will not later be withheld from me. Freedom is essential. And so are the practical benefits. Because tens of thousands of programmers feel the way I do, huge amounts of free software/open source is available, and its quality exceeds that of most proprietary software.

In summary, I use the terms "Linux" and "GNU/Linux" interchangably, with the former being an abbreviation for the latter. I usually use the terms "free software" and "open source" interchangably, as from a licensing perspective they're very similar. Occasionally I'll prefer one or the other depending if I'm writing about freedom, or business advantage.
Steve Litt has used GNU/Linux since 1998, and written about it since 1999. Steve can be reached at his email address.

Letters to the Editor

All letters become the property of the publisher (Steve Litt), and may be edited for clarity or brevity. We especially welcome additions, clarifications, corrections or flames from vendors whose products have been reviewed in this magazine. We reserve the right to not publish letters we deem in bad taste (bad language, obscenity, hate, lewd, violence, etc.).
Submit letters to the editor to Steve Litt's email address, and be sure the subject reads "Letter to the Editor". We regret that we cannot return your letter, so please make a copy of it for future reference.

How to Submit an Article

We anticipate two to five articles per issue. We look for articles that pertain to the GNU/Linux or open source. This can be done as an essay, with humor, with a case study, or some other literary device. A Troubleshooting poem would be nice. Submissions may mention a specific product, but must be useful without the purchase of that product. Content must greatly overpower advertising. Submissions should be between 250 and 2000 words long.

Any article submitted to Linux Productivity Magazine must be licensed with the Open Publication License, which you can view at http://opencontent.org/openpub/. At your option you may elect the option to prohibit substantive modifications. However, in order to publish your article in Linux Productivity Magazine, you must decline the option to prohibit commercial use, because Linux Productivity Magazine is a commercial publication.

Obviously, you must be the copyright holder and must be legally able to so license the article. We do not currently pay for articles.

Troubleshooters.Com reserves the right to edit any submission for clarity or brevity, within the scope of the Open Publication License. If you elect to prohibit substantive modifications, we may elect to place editors notes outside of your material, or reject the submission, or send it back for modification. Any published article will include a two sentence description of the author, a hypertext link to his or her email, and a phone number if desired. Upon request, we will include a hypertext link, at the end of the magazine issue, to the author's website, providing that website meets the Troubleshooters.Com criteria for links and that the author's website first links to Troubleshooters.Com. Authors: please understand we can't place hyperlinks inside articles. If we did, only the first article would be read, and we can't place every article first.

Submissions should be emailed to Steve Litt's email address, with subject line Article Submission. The first paragraph of your message should read as follows (unless other arrangements are previously made in writing):

Copyright (c) 2003 by <your name>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, version  Draft v1.0, 8 June 1999 (Available at http://www.troubleshooters.com/openpub04.txt/ (wordwrapped for readability at http://www.troubleshooters.com/openpub04_wrapped.txt). The latest version is presently available at  http://www.opencontent.org/openpub/).

Open Publication License Option A [ is | is not] elected, so this document [may | may not] be modified. Option B is not elected, so this material may be published for commercial purposes.

After that paragraph, write the title, text of the article, and a two sentence description of the author.

Why not Draft v1.0, 8 June 1999 OR LATER

The Open Publication License recommends using the word "or later" to describe the version of the license. That is unacceptable for Troubleshooting Professional Magazine because we do not know the provisions of that newer version, so it makes no sense to commit to it. We all hope later versions will be better, but there's always a chance that leadership will change. We cannot take the chance that the disclaimer of warranty will be dropped in a later version. 

Trademarks

All trademarks are the property of their respective owners. Troubleshooters.Com(R) is a registered trademark of Steve Litt.

URLs Mentioned in this Issue


_