Wireless-management utilities:




Brief excerpt from a 2004-12 article by Matthew Newton:

At Long Last: Painless Wireless?

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.




Taken from http://www.ccm.ece.vt.edu/~lscharf/samd/?topic=Linux&title=Wireless+PCMCIA+card

Wireless PCMCIA card
Keywords:
Date Created: 2002-04-25
Author: Luke Scharf luke@vt.edu

Here are the things that I wish I'd known before attempting this project:

1. The Linux wireless HOWTO is here:
http://www.tldp.org/HOWTO/Wireless-HOWTO.html

2. Virginia Tech specific information on our wireless network is located here: "TCP/IP, NAT, Firewalls, Etc/Wireless Laptop" http://www.ccm.ece.vt.edu/~lscharf/samd/?topic=TCP%2FIP%2C+NATs%2C+Firewalls%2C+Etc&title=Wireless+Laptop [1]

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:

*,*,*,00:60:1D:*|*,*,*,00:02:2D:*)
INFO="Wavelan IEEE example (Lucent default settings)"
ESSID="ANY"
MODE="Managed"
;;

Make sure that the "KEY=" line is commented or removed.

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.




Date: Mon, 02 Jun 2003 16:50:37 +1000
From: Christopher Wise (chris@wise.id.au)
Subject: Re: encryption for PCMCIA wireless not work in Red Hat 9
To: luv@luv.asn.au

Theng Ung wrote:

>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.

This page has some more distro specific information:
http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/DISTRIBUTIONS.txt

Chris Wise





From: Rick Moen (rick@linuxmafia.com)
Subject: Re: D-Link and Linux: A match made in Hell?
Newsgroups: alt.os.linux.suse
Organization: If you lived here, you'd be $HOME already.
User-Agent: tin/1.7.5-20040615 ("Gighay") (UNIX) (Linux/2.4.24-1-686 (i686))
Date: Wed, 29 Dec 2004 23:20:38 GMT

Timothy J. Bogart (tbogart@frii.net) wrote:

> 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.

[http://ipw2200.sourceforge.net/ :]

> 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.

[1] http://www.wi-fiplanet.com/tutorials/article.php/1428941
[2] http://www.webopedia.com/quick_ref/WLANStandards.asp
[3] http://wiki.tryphon.org/Prism54
[4] http://lwn.net/Articles/108716/?format=printable

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



Mobidik.tk
http://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.




The kde-devel package's ralink graphical utility lets you monitor wireless link quality etc. KDE's KWiFiManager sets up/configures wireless interfaces.




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.




WiFi Radar
http://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.




More at: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html#links