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.
[ 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:
- Learn basic Wi-Fi terminology and theory.
- Set up a proof of concept system, implying you set yourself up a tiny Wi-Fi laboratory.
- 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.
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.
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:

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:

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:

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:

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:

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:

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:

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
- WPA Enterprise
- WPA2 Personal
- WPA2 Enterprise
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.
|
|
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:
- Driver installation
- Association
- 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.
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.
 |
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:
- They provide a time saving quickstart.
- They automatically install the needed drivers, with at least some autodetection.
- 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:
- The access point
- Daemons
- ifplugd
- wlandetect -d
- zcip
- dhclient
- Files
- ifcfg-wlan0 (or ifcfg-ath0 or ifcfg-rausb0 or whatever)
- /etc/sysconfig/networkscripts/wireless.d/*
- /etc/wpa_supplicant.conf
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:
- It usually works
- It often works better
- It's installable in a predictable manner
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 |
|
|
|
|
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.
- Obtain necessary software
- Windows driver
- cabextract
- dhcp-client
- wireless-tools
- wpa_supplicant
- ndiswrapper
- Firmware extractor (like bcm43xx-fwcutter) if firmware extraction is needed
- Install the driver
- su -
- cd <directory with drivers>
- Extract drivers from .exe collection if necessary
- Extract firmware to /lib/firmware/ if necessary (for instance, Broadcom 43xx)
- ndiswrapper -i drivername.inf
- ndiswrapper -l
- ndiswrapper -m
- depmod -a
- tail -fn0 /var/log/messages (in another terminal)
- modprobe ndiswrapper
- Test the driver
- Verify existence of simple wlan0 config file
- DEVICE=wlan0
- BOOTPROTO=dhcp
- ONBOOT=yes
- Create the wlan0 config file if necessary
- iwlist wlan0 scanning
- Connect (associate) to an access point
- iwconfig wlan0 mode Managed
- iwconfig wlan0 essid any
- ifdown wlan0
- ifup wlan0
- Wait up to a minute
- ifconfig wlan0
- Look for IP address, which indicates association and DHCP success
- Create a connection script
- Run the connection script
- Verify IP, netmask, gateway and DNS
- ping troubleshooters.com
- Troubleshoot as necessary
- 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:
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:
- "Personal Router" such as the Linksys WTR54G gives total info on all nearby access points
- "Hotspot Finder" tells whether there is a nearby access point, and how strong
- Windows computer or the client computer casts a tie breaking vote.
- Take it to the library, where they have what you can assume is a known good access point.
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:
- Erase any firmware, for this device, that you placed in /lib/firmware
- delmod ndiswrapper
- lsmod | grep ndis
- To make sure it's really gone
- depmod -a
- Put your modules in proper state
- rm /etc/modprobe.d/ndiswrapper
- vim /etc/modprobe.conf /etc/modprobe.d/ndiswrapper
- Remove any line associating wlan0 with ndiswrapper
- ndiswrapper -l
- Get the name of the Windows driver
- ndiswrapper -e <windows driver name>
- ndiswrapper -l
- Verify the windows driver is gone
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.
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.
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!
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:
- Command line only
- 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:
- In one terminal, tail -fn0 /var/log/messages
- Plug in the WUSB54G version 4 wireless NIC
- Note the "tweaked" driver name referenced in /var/log/messages
- Find the "true" driver name with lsmod | grep usbcore
- Create a simple /etc/sysconfig/network-scripts/ifcfg-rausb0
- echo alias rausb0 rtusb >> /etc/modprobe.conf
- Reboot the computer
- Try iwlist rausb0 scanning
- If necessary, try one or more ifdown rausb0 and ifup rausb0
- Back up /etc/modprobe.conf
- 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:
- Click the "Network & Internet" tab
- Click the "Set up a new network interface" icon or link
- Choose "Wireless" from the list
- Click the "Cisco-Linksys|Wireless-G USB Network Adaptor" radio button and click the Next button
- Fill in the rest of the prompts as appropriate
- 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.
- Exit drakconf
- iwlist rausb0 scanning
- 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.
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.
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.
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
_