It's been more than a year since I chronicled my travails in getting
Wi-Fi to work on my trusty Thinkpad, and not much has changed. If I am
at home, the machine connects quickly and effortlessly to my home
network, whose parameters (network name, WEP encryption key) are stored
in the wireless configuration for Mandrakelinux 10.1, which I'm now
running.

But when I'm elsewhere, trying to connect to an open wireless network,
the Gnome desktop falls short. I have to open a terminal window,
disassociate from any existing network with "iwconfig ath0 essid any",
turn off WEP with "iwconfig ath0 key off", scan for the public network
with "iwlist scan", and finally connect to the network and grab an IP
address with "iwconfig ath0 essid networkname" and "dhclient ath0". That's
hardly the epitome of user friendliness. I don't need a computer that
holds my hand every step of the way, but I also have no desire to mess
around with the command line for something as simple (from an end-user
perspective, anyway) as connecting to a wireless network. I'm guessing
you feel the same way.

So when Novell was here at PC World HQ several weeks ago, showing off
Novell Linux Desktop 9, I was intrigued by an applet running in the demo
machine's Gnome panel. A right-click on this applet showed all available
wireless networks and their signal strengths. Selecting any listed
network made the machine connect to that network. Simple! Elegant!
Something that Just Works! I was salivating. I wanted that applet right
away. I asked the Novell reps where it came from. They told me that it
was a custom bit of work by the coders at Novell, and that, in due time,
the code would flow back to the wider Gnome project.

It turns out that wasn't true at all. The applet I saw is known as
NetworkManager, and it's actually a clever bit of work spearheaded by a
coder at Red Hat.

3. Wireless networks come in two general flavors. The Linux
folks
call them "Managed" and "Ad-hoc". The Managed flavor is a large
wireless
network consisting of many access points. The NIC will go out and
scan
for the best access point and use that one. You do not have to
specify
things like the channel or the name of the access point. The
Ad-hoc
flavor is designed for a residence or workgroup - use this if you
want
the client to connect to one particular access point. As far as I
know,
the Managed and Ad-hoc modes are mutually exclusive - you can't
use the
Managed mode of the card to automatically search for access
points in
the Ad-hoc mode.

4. The Virginia Tech wireless network runs in Managed
mode.

5. /sbin/iwconfig is a wireless-specific supplement to
/sbin/ifconfig. It will allow you to monitor the wireless
connection
type and quality. While I was successful in changing the essid
and
switch the card into managed mode, I was not able to do this and
then
get an IP address via DHCP.

6. The default setting for the card I used ("Lucent
Technologies
Orinoco", AKA "wavelan") is to run in Ad-hoc mode. I was able to
change
the setting on RedHat 7.2 by adding the following line to
/etc/pcmcia/config.opts:

module "wvlan_cs" opts "station_name=MY_PC"

A commented-out version of this line is provided in the
default
version of the file - but I missed this the first ten times
through the
file. Also, the easiest way to get the system to reread this file
seems
to be rebooting. The exact line vary depending on your NIC, and
I'm sure
that different distributions do things in a totally different
way. But
this was the key part that I was missing.

7. A similar change is required to /etc/pcmcia/wireless.opts.
Make
the "Lucent Wavelan IEEE (+ Orinoco, RoamAbout and ELSA)" section
look
like this:

8. Linux appears to set the default TCP/IP route and gateway
when the
first network card starts. This means that if the wired ethernet
card is
eth0 and the wireless is eth1, then you have to shut down eth0
once you
unplug the wire.

[1] Quoting that document:

There are some hurdles to using the Virginia Tech wireless
network:

* If you're faculty/staff you have to fill out a paper form
to
register the MAC address of your card. If you're a student,
you
merely have to drop by the DNS Student Telecommunications
office.
See http://wireless.cns.vt.edu for
more information.
* IP addresses are assigned to wireless clients via DHCP. The
DHCP
server will not assign you an IP address unless you register
with
CNS. This is a reasonable security precaution.
* The essid should be off or "ANY"
* See "Linux/Wireless PCMCIA card" for information on
configuring
Linux to use a wireless card.

>I has setup MA401 802.11b PC card to talk Netgear
>ME102 802.11b Wireless Access Point and seems to work
>fine without encryption but won't work with 128bits
>encryption using the same key that work in XP.
>
>Search on google only show people using Red Hat 7.3
>and using a different driver rathern the default with
>Red Hat 9. Also there is a mention of enter key in
>this format AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66
>that dont help either.
>
I think that you need to use the format
AABB-CCDD-EEFF-0011-2233-4455-66.
That's what iwconfig seems to like. My experience with Mandrake,
but I
just looked on a Redhat box and the
/etc/sysconfig/network-scripts/ifup-wireless script seems
simmilar.

> So, you did not cite an FCC 'rule' which makes it illegal to have open
> source drivers. As expected.

The matter really does need to be FAQed, since there's a lot of dubious
information on the subject.

Near as I can tell, the real underlying facts are these: the USA's FCC
does have rules requiring that services stay within their assigned
frequency bands and not exceed their mandated effective isotropic
radiated power (EIRP) limits. Manufacturers of wireless equipment are
mindful of those restrictions, and probably wary of giving customer easy
means to violate either frequency or power restrictions, lest they be
held liable on some theory of secondary liability. (Manufacturers are
responsible for complying with FCC's Part 15 rules section 247[1] as to
EIRP, and with frequency assignments elsewhere in Part 15.)

When IEEE finished the 802.11g standard, for example, the spec included
14 channels in the 2.4GHz band, but FCC allows use of only 11 of those
for WiFi service.[2] So, any card capable of 802.11g has the physical
capability to use all 14 channels, but the released drivers restrict the
card to the FCC's 11 channels.

Some recent cards (e.g., Prism GT, Duette, and Indigo ones) package the
card's low-level programming in the previously mentioned "binary
firmware images". These are blobs of binary that would otherwise have
been _in_ firmware (as it is in, say, my old Lucent Orinoco 802.11b
card), but the manufacturer elected to save money on the ROMs in this
fashion.

This in itself isn't a big problem: One just configures the hotplug
system to lob the binary image into the card at initialisation time.[3]
The only real problem is that the manufacturers basically never bother
issuing permission for the public to redistribute those binary blobs[4],
so most distributions, not wanting to step into a legal quagmire, don't
include them. Which in turn forces each user to hunt them down
independently and install them into /etc/hotplug locally.

Note that the "firmware image" is not a driver; it has no OS
dependencies. Equipped with such an image file and rudimentary
information about how to load it, one could code a driver, either open
source or not, for any operating sytsem.

> So I looked at the ipw stuff. Duh. It is the Intel stuff. They
> don't release full documentation for their stuff. The firmware is
> from Intel and you have to agree to an Intel license agreement to use
> it. Not pure GPL.

The fact that the IPW firmware images are binary-only and restricted to
be lawful only in use with Intel hardware isn't a huge problem: The
firmware code stored inside my Lucent Orinoco is, in effect, just as
restricted — as is, most likely, the ROM BIOS code stored inside your
motherboard and mine. Otherwise, the licence is non-transferrable and
bars use in reverse-engineering but at least allows distribution to
users. So, unlike many such images (e.g., Intersil's for the Prism
chips), it could be lawfully included in Linux distribution media.

Having source code to that firmware, or to an independent
reverse-engineering of that code, would be nice but is certainly not
essential for the hardware's full usability on Linux or any other OS --
not any more than it's necessary to have your motherboard's ROM BIOS
code to run open-source OSes on it.

Anyhow, your overall point is well-taken: As far as I can see, nothing
in FCC's ruling precludes developing and using fully open source
drivers, per se. Most manufacturers are being uncooperative for reasons
of their own; probably not explicit policy but just inertia and fear of
even indirect association with coders modifying their firmware to
increase EIRP and/or change the frequencies used.

--
Cheers, Hardware: The part you kick.
Rick Moen Software: The part you boot.
rick@linuxmafia.com

Mobidik.tkhttp://www.mobydik.it
Mobodik.tk is Paolo Cavone's tcl/tk graphical wrapper for the Linux
Wireless Extensions Tools, maintaining a list of previously known
wireless networks (for re-selection), showing all wireless networks
in the immediate vicinity with their signal strengths, and allowing easy
selection of any of those.

As of Feb. 2005, Paolo mentions that the Mobodik.tk Web site will
soon be available in the English language.

GNOME network-manager:
NetworkManager attempts to keep an active network connection available
at all times. It is intended primarily for laptops where it allows easy
switching betwen local wireless networks, it's also useful on desktops
with a selection of different interfaces to use. It is not intended for
usage on servers.

Wireless Tools / Wireless Extensions:http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
The Wireless Extension (WE) is a generic API allowing a driver to expose
to the user space configuration and statistics specific to common
Wireless LANs. The beauty of it is that a single set of tool can support
all the variations of Wireless LANs, regardless of their type (as long
as the driver support Wireless Extension). Another advantage is these
parameters may be changed on the fly without restarting the driver (or
Linux).

The Wireless Tools (WT) is a set of tools allowing to manipulate the
Wireless Extensions. They use a textual interface and are rather crude,
but aim to support the full Wireless Extension. There are many other
tools you can use with Wireless Extensions, however Wireless Tools is
the reference implementation.

iwpriv allow to manipulate the Wireless Extensions specific to a
driver (private)

ifrename allow to name interfaces based on various static criteria

WiFi Radarhttp://wifi-radar.systemimager.org/
WiFi Radar is a Python/PyGTK2 utility for managing WiFi profiles.
It enables you to scan for available networks and create profiles for
your preferred networks. At boot time, running WiFi Radar will
automatically scan for an available preferred network and connect to it.
You can drag and drop your preferred networks to arrange the profile
priority. WiFi Radar is tested to work with Centrino's WiFi card
IPW2100 but should work just the same for any iwconfig interface.