2.3 Four Steps to Wi-Fi

 <  Day Day Up  >  

To use a Wi-Fi card on your Linux system, you need several things:

  • The correct driver software for your Wi-Fi card

  • The Linux Wireless Tools software

  • If your system uses a PC Card interface for the Wi-Fi card, the pcmcia-cs software package must be installed and configured OR

  • Your kernel must have kernel PCMCIA support compiled in. You may need to recompile your kernel, depending on your system and distribution.

If you installed your Linux distribution on a notebook or laptop, there's a good chance that you already have at least part of the necessary packages to make a configured and operational Wi-Fi network card. Current versions of Red Hat, Debian, and SuSE with 2.4 kernels all include a "notebook" option during the installation process that installs kernel PCMCIA support.

You have two options for PCMCIA support in Linux: the pcmcia-cs package or kernel PCMCIA support. All 2.4.x distributions of the Linux kernel include the option for compiling in PCMCIA support, which removes the need for the external pcmcia-cs package. However, there are some valid reasons to use the pcmcia-cs package rather than the kernel PCMCIA support, which we discuss later in this section.

Kernel PCMCIA support is based on the pcmcia-cs package. The pcmcia-cs README for Version 2.4 kernels, found at http://pcmcia-cs. sourceforge .net/ftp/README-2.4, has several good questions on this topic:

Q: Are these two versions of PCMCIA both going to continue with active development?

A: The kernel PCMCIA subsystem should be the focus for ongoing development. The standalone pcmcia-cs drivers are still being maintained but the focus has shifted from adding functionality, towards mainly bug fixes.

Q: Which should I use / which is better? The kernel PCMCIA, or the standalone PCMCIA?

A: It rarely matters. The client drivers should generally behave the same. At this point, most current distributions use the kernel PCMCIA subsystem, and I recommend sticking with that unless you have a particular need that is only met by the standalone drivers.

Your Linux distribution may not install the Linux Wireless Tools or the pcmcia-cs packages by default. You must select these packages during the installation process or add them at a later time.

You don't need to install both kernel PCMCIA and pcmcia-cs.


The same is true for many wireless drivers. Most current Linux distributions give you drivers for some common Wi-Fi cards, including the orinoco_cs driver for Lucent WaveLan/Orinoco cards. However, if you need the hostap, wlan-ng, or madwifi drivers, you must install these from source, or optionally from a binary package that a third party has made available.

2.3.1 Linux Wi-Fi Drivers

We can't cover all Wi-Fi radio cards, their features, and the available drivers for them. We'll discuss several of them briefly and cover the four most useful drivers for Linux in more detail at the end of this chapter:


Hermes AP

Hermes AP is a patched version of the orinoco_cs driver that allows you to use the " tertiary " code available for Orinoco cards, which allows them to act as an access point. You can find the driver at http://hunz.org/hermesap.html.


hostap_cs

This is a driver for Prism II cards but with a few features not found in other drivers. You can find the driver at http://hostap.epitest.fi. See Section 2.4.2 later in this chapter.


madwifi

This driver supports the Atheros 802.11a/b/g radio cards. You can find this driver at http://sourceforge.net/projects/madwifi. See Section 2.4.4 later in this chapter.


orinoco_cs

This driver supports Lucent WaveLAN IEEE, Lucent Orinoco, Symbol Spectrum 24, and Apple AirPort (but not AirPort Extreme) cards, and is included with most recent Linux distributions. This driver also supports Prism II cards, but most features of the Prism II chipset are not supported. You can download the driver from http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Orinoco.html. See Section 2.4.1 later in this chapter.


prism54

The prism54 driver supports cards based on Prism GT, Prism Duette, and Prism Indigo chipsets. You can find this driver at http://prism54.org/.


wlan-ng

This is another Prism II driver. It does not support the wireless-tools package, but it does come with its own utilities. You can download the driver from http://www.linux-wlan.org/. See Section 2.4.3 later in this chapter.

2.3.2 Configuring and Compiling Your Kernel

There are a number of reasons why you should consider compiling your own Linux kernel from source:

  • Many drivers require certain features to be compiled into the kernel that are not available in stock distribution kernels. For example, the madwifi driver requires not only radio support and the wireless tools, but also PCI Hotplug and ACPI support, which must be compiled into the kernel.

  • Other drivers, while not requiring experimental kernel features, still require a configured kernel source. A .config file must exist in the root of your kernel source and must be the file that was used to configure and compile your running kernel. Some Linux distributions do not include this file, which makes it difficult for you to install kernel drivers.

  • You should know how to compile a Linux kernel. If you have used Linux for any length of time, or if you plan to, kernel compilation teaches you a great deal about Linux.

Compiling the Linux kernel from source is not a trivial undertaking. While you don't need prior experience building system-level software, you do need a basic understanding of Linux filesystems, editors, and other concepts. See the following resources for some good basic Linux backgrounders:

  • The Linux Kernel HOWTO, part of the Linux Documentation Project (http://www.linux.org/docs/ldp/howto/Kernel-HOWTO/index.html)

  • Running Linux , Fourth Edition (O'Reilly)

  • Understanding the Linux Kernel , Second Edition (O'Reilly)

To configure and compile a Linux kernel, you must obtain the following items:

  • A working Linux system

  • The correct compiler, libraries and tools

  • The kernel source

A working Linux system should be fairly modern if you are planning on compiling modern kernel code. For instance, do not attempt to compile a 2.4 kernel tree using a Linux system based on a 2.0 or prior kernel. Any recent distribution of Linux should have the kernel version and tools necessary for compiling your own kernel.

In each kernel release, the README file in the kernel source specifies the version of the gcc compiler needed to compile successfully. For example, the README for kernel 2.4.22 states:

Make sure you have gcc 2.94.3 available. gcc 2.91.66 (ecgs-1.1.2) may also work but is not as safe, and gcc 2.7.2.3 is no longer supported.

Compiling and running the 2.4.xx kernels requires up-to-date versions of various software packages. Consult /Documentation/Changes for the minimum version numbers required and how to get updates for these packages.

The Changes document goes into great detail on versions of software, including gcc, that are required for successful compilation of the kernel source. Make sure your system has the correct versions of the tools specified. Failure to do so may mean that your new kernel will not compile, or that bugs will be introduced into your kernel.

Kernel source can be obtained from many places. The major distributions include kernel source in package format ”RPMs, Debian packages for apt-get, or dpkg. Other kernel source RPMs built by third parties can be found at http://www. rpmfind .net. The ultimate repository for all Linux kernels is kernel.org, accessible via FTP or HTTP. Here you can find source for any kernel version you want, all the way back to the 1.0 kernel from 1994.

The latest stable kernel is Version 2.4.23, and it can be downloaded directly by using this URL: http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.23.tar.bz2. You'll want to save this compressed file in /usr/src .

To find the latest kernel source, look in the major/minor version subdirectory (such as v2.4 ) for a file starting with LATEST-IS. For example, a file named LATEST-IS-2.4.23 tells you that kernel 2.4.23 is the most recent. Unless you are aware of a specific problem with the latest kernel version, you should always use the most recent one.


We'll walk through a compile of the 2.4.23 kernel for a Debian Linux system running on a Dell laptop. Obviously, this only scratches the surface of kernel compilation. This book doesn't have the space to cover multiple versions of kernels, much less cover what it takes to compile on other specific systems. One good resource for information is the Kernel HOWTO listed earlier. Another is the linux-kernel mailing list, located at http://www.tux.org/lkml/. This page has a very extensive questions section, where many common kernel answers are given.

2.3.2.1 Off to the races

Assuming that you have obtained the 2.4.23 kernel source from www.kernel.org , you'll want to uncompress the file and change into the working source directory (these instructions will work with later versions of the 2.4 kernel):

 #  tar xjvf linux-2.4.23.tar.bz2  #  cd linux-2.4.23  

If you want to save the original .config file from the source, you should back it up (if you obtained your kernel source from a tarball at kernel.org, this file won't exist):

 #  cp .config .config-original  

If you have done anything in this directory other than the three commands listed previously, it's a good idea to run a couple of cleanup commands. These commands clean out all sorts of things that might have been compiled or configured in ways that you don't want:

 #  make clean  #  make mrproper  

At this point, you have four options for configuring your kernel before compilation.


Manual editing of the .config file

Not recommended unless you are a serious kernel hacker, and you know exactly what you're doing.


make config

This is a command-line interface that walks you through every possible config option, one at a time. It is very time consuming and very unfriendly. When you enter this command, you see something such as this on the screen:

 rm -f include/asm ( cd include ; ln -sf asm-i386 asm) /bin/sh scripts/Configure arch/i386/config.in # # Using defaults found in .config # * * Code maturity level options * Prompt for development and/or incomplete code/drivers (CONFIG_ EXPERIMENTAL) [Y/n/?] 

You must answer each and every question the script asks you in order to generate a valid .config file.


make menuconfig

This is a command-line menu interface that relies on the ncurses library to generate a menu-based configuration editor. It is a much more friendly interface than the preceding options. Here, instead of answering a question about each and every single possible kernel feature, you are presented with a hierarchical menu that breaks things down into sections. Figure 2-2 shows the main menu you obtain from running make menuconfig .

Figure 2-2. Initial menu from make menuconfig
figs/luw_0202.gif

make xconfig

As the name implies, this is an X-Windows interface for the config process. You must be running some flavor of X-Windows to use this option. For most Linux users, this is Gnome or KDE. make xconfig produces a GUI window, as shown in Figure 2-3.

Figure 2-3. Initial menu from make xconfig
figs/luw_0203.gif

For most users, make menuconfig or make xconfig are going to be the most friendly. This book assumes that you have chosen one of these options. Every option in the following list that you pick is from a menu in make menuconfig or make xconfig .

The following list presents a number of options that you must choose to successfully compile your kernel for wireless connectivity. Note that there are many other options that must be selected to compile a kernel for your system, but they are not covered here. There are three options you can select: Y for yes, M for module, and N for no:

  Code maturity level options  Prompt for development and/or incomplete code/drivers: Y  Loadable Module Support  Enable loadable module support: Y      Set version information on all module symbols: Y      Kernel module loader: Y  Processor type and features  It is   vitally   important that you select your correct processor type      in this option.  Otherwise your kernel will not be compiled properly     and will definitely not boot.  General Setup  Networking support: Y      PCI Support (for PCI or CardBus wireless cards): Y      Support for hot-pluggable devices (for PCMCIA, CardBus or USB support) Y  PCMCIA/CardBus support  PCMCIA/CardBus support: Y          CardBus support (if required for your setup): Y  PCI Hotplug Support  Support for PCI Hotplug (required for madwifi driver): Y          ACPI PCI Hotplug driver (required for madwifi driver): M  Power Management Support (required for ACPI): Y   ACPI Support  ACPI Support (required for madwifi driver): Y  Plug and Play configuration  Plug and Play support: Y  Networking options  Packet socket: Y      Socket filtering: Y      Unix domain sockets: Y      TCP/IP networking: Y  Network device support  Network device support: Y     Wireless LAN (non-hamradio): Y         In this section you will want to choose a wireless          driver for your card, if it is listed here. 

Once you have selected these options (and any other options required for your particular system), you're done with the config. You can choose to Store Configuration to File if you would like to write this particular config to a file other than the default .config . Otherwise, choose Save and Exit, which writes your options to the .config file.

Your next step is to issue the make dep command. This runs a Makefile script that compiles any dependencies required for your kernel. Depending on your system, this likely takes a few minutes.

You're now ready to compile the kernel! This is done with the make bzImage command. This takes quite some time.

Next, because you have selected the Loadable Modules section, you must compile all of the modules by issuing the make modules command. On some systems, depending on the number of modules you chose to build, this command may take more time than compiling the kernel.

Finally, you must install the modules you have just compiled. This is accomplished by the make modules_install command.

If you encounter errors during the compile process, note the specific error and the directory in which it occurred. Execute the make clean command. Go back into make xconfig and find the area corresponding to the directory where the compile failed. Examine the options you chose very carefully . Did you choose a kernel option or module that is not on your system? Did you choose an option that is labeled as EXPERIMENTAL ? You may wish to alter your choices. While the menu makes choosing kernel options very easy, it does not give you advice on which options to choose. You may have to experiment with the settings until you get a successful compile.

Once you have compiled the bzImage and the modules, you are ready. Now, you must copy the bzImage file that was compiled to your /boot directory. Many distributions use the filename of vmlinuz for this purpose, but you can call the file anything you want. The path below obviously varies depending on your system architecture. The following example is from kernel 2.4.23 compiled for i386:

 #  cp /usr/src/linux/arch/i386/boot/vmlinuz-2.4.23 /boot/  

One last thing must be done: configure your boot loader program so that it recognizes your new kernel. The two most common boot loaders are GRUB and LILO. LILO is the older of the two, but it is still widely used. We assume that you are using LILO. For more information on configuring GRUB, see the GNU software pages at http://www.gnu.org/software/grub.

To configure LILO for your new kernel, edit the /etc/lilo.conf file. A typical lilo.conf is shown here:

 lba32 boot=/dev/hda root=/dev/hda3 install=boot/boot-menu.b map=/boot/map delay=20 prompt timeout=150 vga=normal default=Linux image=/boot/vmlinuz-2.4.23     label=Linux     read-only image=/boot/vmlinuz-2.4.18     label=Old Kernel     read-only 

The key pieces are at the end. This example uses default=Linux , the label associated with the image for kernel 2.4.23, which you have just built and copied to /boot . Leave the old kernel image in the configuration file. This is very important, because it gives you a rescue option if your new kernel image does not boot or has errors.

To activate this lilo.conf , run LILO and specify the configuration file:

 #  lilo -C /etc/lilo.conf  Added Linux * Added Old Kernel 

You are now ready to reboot your system and boot into the new kernel that you just compiled.

2.3.3 Building and Configuring the pcmcia-cs Subsystem

As mentioned previously, you have two options for PCMCIA support. You can select PCMCIA/CardBus support when you compile your kernel, or you can build the pcmcia-cs subsystem from scratch.

The pcmcia-cs software package, available from http://pcmcia-cs.sourceforge.net, is the basis for the kernel PCMCIA support. Going forward into the 2.6 kernels, it appears that all new development will be on the kernel tree PCMCIA. However, as of this writing and the 2.4.23 kernel, the pcmcia-cs version of 3.25 has newer utilities and drivers than the ones in the kernel PCMCIA. It is mainly for this reason that you will want to compile pcmcia-cs from source.

If you compile your kernel with PCMCIA/CardBus support, you do not need to install the pcmcia-cs package from source. However, if you want the latest versions of the PCMCIA utilities, you can install this package without interfering with kernel support for PCMCIA/CardBus. For more information, see Section 2.3.3.1 later in this chapter.


Once again, to compile kernel modules from source, you need the configured kernel source for your kernel. This generally means that you have configured and compiled your own Linux kernel. While it is certainly possible to compile kernel modules against Linux kernels provided by a stock distribution, it can be tricky. For more on compiling your own kernel, see the previous Section 2.3.2.

There are a number of kernel options that may need to be enabled, depending on how you use the PCMCIA devices. Because many of these options pertain to wired network cards, SCSI and IDE adapters, we do not cover them here. However, if you do plan to use 16-bit PCMCIA (non-CardBus cards), you must enable CONFIG_ISA. This option can be found in the General Setup portion of make menuconfig or make xconfig as part of your kernel configuration.

To begin compiling the package, download the pcmcia-cs.3.2.5.tar.gz file into the /usr/src directory. Unpack the tar.gz file and change into the top-level directory (if a later version is available, you should use that):

 #  tar xzvf pcmcia-cs.3.2.5.tgz  #  cd pcmcia-cs.3.2.5  

You must configure the package before compilation and make a few decisions on what kind of PCMCIA support you need. In most cases, you can accept the defaults on all of the config questions.

The kernel source directory defaults to /usr/src/linux . If your kernel source is located in /usr/src/kernel-2.4.23 , you must enter that here:

 #  make config  Linux kernel source directory? 

Next, you can choose whether to allow non-root users to modify PCMCIA card configurations. The default answer is no, which does not allow any non-root users to suspend, resume, or reset cards, or to change the PCMCIA configuration scheme. Answering yes allows non-root users all these privileges.

 Build 'trusting' versions of card utilities? 

In most cases, you want to enable CardBus support. Unless you plan only to use 16-bit 802.11 and 802.11b PCMCIA cards, CardBus is required for 802.11a and 802.11g PC Cards.

 Include 32-bit (CardBus) card support? 

This option inserts extra code into the PCMCIA subsystem, which allows it to check with a system's BIOS to obtain resource information on a motherboard's devices to help avoid resource conflicts. It can cause problems on some laptops, so this option is not enabled by default.

 Include PnP BIOS resource checking? 

Unless you are installing modules in an alternate directory for some reason, this should be the subdirectory of /lib/modules that matches your kernel. In this case, the subdirectory is /lib/modules/2.4.23 .

 Module install directory? 

Once you've answered the questions and config has finished, you should run the following commands to build and then install the kernel modules and utility programs:

 #  make all  #  make install  

Once installed, the kernel modules will be located in /lib/modules/2.4.23/pcmcia , the binary PCMCIA control programs will be located in /sbin , and all configuration files will be located in /etc/pcmcia . A startup configuration file will also be installed, but this location varies with the Linux distribution in question. Debian locates the startup configuration in /etc/default/pcmcia . RedHat and several other distributions locate the startup configuration in /etc/sysconfig/pcmcia .

The startup configuration file has several options that can be set. A sample file from a modified Debian system looks like this:

 PCMCIA=yes PCIC=i82365 PCIC_OPTS= CORE_OPTS= CARDMGR_OPTS=-f 

If PCMCIA is set to anything other than "yes," the PCMCIA subsystem will not start at time of boot.

The only mandatory option in this file that must be set is PCIC=. There are three options: tcic, i82365, and yenta_socket. tcic is a driver for older PC Card controllers, and unless you're building on a 486 laptop, you won't use it. Most other systems will want to set this option as i82365, unless you have the kernel tree PCMCIA. If the kernel tree PCMCIA is configured in your kernel, you must set this option to yenta_socket. Finally, if your PCMCIA card is CardBus, you should set this to yenta_socket.

PCIC_OPTS are necessary only if your specific PC Card controller has options that need to be passed to it at boot time. For most modern controllers, this is not an issue.

CORE_OPTS are options for the kernel module pcmcia_core. man pcmcia_core gives you a listing of all these options.

CARDMGR_OPTS are options for the cardmgr daemon. man cardmgr gives you a listing of these options. In this case, the -f option tells cardmgr to run in the foreground, rather than as a daemon, until any cards present are already configured.

There are quite a number of settings that are possible for various systems. If you have an unusual system or a desktop system with an add-on PCMCIA reader, you should completely read through the PCMCIA HOWTO:

http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO.html
2.3.3.1 2.4 kernels and kernel tree PCMCIA

Note that if you have a 2.4 kernel and kernel tree PCMCIA configured in your kernel, the pcmcia-cs install process will install only the PCMCIA tools, cardmgr, and cardctl in the /sbin directory. None of the kernel modules or client card drivers will be installed, because the pcmcia-cs installer will find existing modules from the kernel tree PCMCIA and by default will not overwrite them.

Included with the pcmcia-cs source is a README file on issues with the 2.4 kernel. (You can also find this file at http://pcmcia-cs.sourceforge.net/ftp/README-2.4.) One of the questions in the Q&A section covers this issue. You cannot compile or install anything in the /usr/src/pcmcia-cs.3.2.5/modules directory, as these modules would conflict with the PCMCIA subsystem in the kernel tree.

However, you can build client card drivers from the pcmcia-cs source code by executing make install in either the /usr/src/pcmcia-cs.3.2.5/ clients or /usr/src/pcmcia-cs.3.2.5/wireless subdirectories after running make config .

You may need to build the drivers this way for a variety of reasons. For example, when we built and compiled the 2.4.23 kernel, pcmcia-cs, and associated wireless drivers, we discovered that the madwifi driver for Atheros chipsets required kernel tree PCMCIA. However, once the kernel was compiled and the Atheros card was successfully tested , we discovered that the Orinoco card would not initialize. The PCMCIA subsystem reported orinoco_cs: CardServices release does not match! In order to fix this, it was necessary to configure pcmcia-cs and run a make install in the wireless subdirectory, as described earlier.

2.3.3.2 Controlling the PCMCIA subsystem

To successfully initialize and configure a PCMCIA wireless card, there are a number of pieces that come into play. Three modules need to be loaded at boot time: ds , i82365 or yenta_socket , and pcmcia_core . If you have kernel tree PCMCIA enabled or have gone through the pcmcia-cs installation process, these modules load automatically.

The next important bit is the cardmgr daemon, which monitors the PCMCIA socket, loads client card drivers at startup, and runs user scripts when cards are inserted or removed. The two important files for cardmgr are located in /etc/pcmcia/config and /etc/pcmcia/config.opts . config contains information about all of the client card drivers, about how to identify various cards, and about which drivers to load for which card. This file shouldn't be modified unless you really know what you're doing and must load a driver for a card that is not described in the config file. Similarly, config.opts must be modified if you have special options that must be passed to the PCMCIA card from cardmgr, or if you are experiencing memory or address conflicts with a specific card.

To manage a given PCMCIA card, run a user-space program called cardctl . cardctl checks the status and configuration of a PCMCIA socket and allows you to modify the configuration, as well as insert, eject, and suspend PCMCIA cards. There are several commands that cardctl supports. Examples with sample output from the commands are shown next.

The config command shows low-level configuration for any PCMCIA card: the voltage type, interface type, IRQ in use, and I/O memory used. This is a very handy tool for troubleshooting if you are running into resource conflicts.

 #  cardctl config  Socket 0:   Vcc 3.3V  Vpp1 0.0V  Vpp2 0.0V   interface type is "memory and I/O"   irq 12 [exclusive] [level]   function 0:     config base 0x03e0       option 0x41     io 0x0100-0x013f [16bit] 

The ident command gives you the chipset identification strings for your PCMCIA card. In this example, you are looking at a Senao 802.11b card that uses the Intersil Prism II chipset. Note that one thing you don't see is the manufacturer name; rather, you see the chipset manufacturer name.

 #  cardctl ident  Socket 0:   product info: "INTERSIL", "HFA384x/IEEE", "Version 01.02", ""   manfid: 0x0156, 0x0002   function: 6 (network) 

The suspend and resume commands shut down a PCMCIA card without unloading the associated drivers, and then they allow you to resume normal card operation. reset reloads the card driver without shutting down power to the card or resetting the PCMCIA subsystem.

 #  cardctl suspend  #  cardctl resume  #  cardctl reset  

The eject and insert commands are the software equivalent of physically ejecting and inserting a PCMCIA card, so the card drivers are loaded or unloaded, and the devices are configured or shut down. It's important to note that CardBus cards may not react well to physical ejection, and you should use the cardctl eject command before removing a CardBus card.

 #  cardctl eject  #  cardctl insert  

Schemes allow you to have multiple configurations for your PCMCIA card. With a wireless network card, multiple schemes provide you with the ability to change ESSID and other wireless settings as well as TCP/IP configuration. Schemes are covered in more detail in the discussion of the PCMCIA configuration.

 #  cardctl scheme  

To stop or start the entire PCMCIA subsystem, execute the rc script that is installed with pcmcia-cs or the kernel tree PCMCIA. Where this file is located varies depending on your Linux distribution. On most Linux distributions, these commands stop and start the PCMCIA subsystem:

 #  /etc/init.d/pcmcia stop  #  /etc/init.d/pcmcia start  
2.3.3.3 PCMCIA wireless card configuration

PCMCIA devices are grouped into classes that define how they are configured and managed. These classes include network, SCSI, CDROM, fixed disk, serial, and a couple of memory card classes. This chapter is really concerned with wireless network cards, so the only class that is discussed here is the network class.

When the Wireless Tools are installed (see Section 2.3.4 later in this chapter for more information), an additional class is added: wireless.

Classes are associated with device drivers in /etc/pcmcia/config . Each class has two scripts located in /etc/pcmcia : a main configuration script and an options script. For network cards, these scripts are /etc/pcmcia/network and /etc/pcmcia/network.opts . Similarly, the wireless class scripts are /etc/pcmcia/wireless and /etc/pcmcia/wireless.opts .

Both config scripts extract some information about the PCMCIA card from the PCMCIA subsystem and use this information to generate a device address. The first part of any PCMCIA device address is the current scheme.

While the PCMCIA scripts accept any number of parameters in the device address, the sample scripts use the following syntax:

 case "$ADDRESS" in *,0,*,*)     # definitions for network card in socket 0     ;; *,1,*,*)     # definitions for network card in socket 1     ;; esac 

The comma-separated fields in this example are the scheme, the socket number, the device instance, and the card's hardware Ethernet address. The device instance is used only if the card has multiple network interfaces, so, in most cases, it is zero. In this example, the cards are configured based on their socket number, which is somewhat easier to manage than configuration based on hardware Ethernet address.

The network.opts file accepts a large number of parameters. For information on all that this file offers, read through the PCMCIA HOWTO:

http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO.html

It is also beneficial to read through the default /etc/pcmcia/network.opts file before making any changes. Back up the file before you start editing:

 /etc/pcmcia#  cp network.opts network.opts.orig  

Here is a sample of a configured network.opts file that sets up a static IP address and related TCP/IP address information for the wireless network card in slot 0:

 case "$ADDRESS" in *,0,*,*)     INFO="Sample network setup"     IPADDR="10.42.7.2"     NETMASK="255.255.255.192"     NETWORK="10.42.7.0"     BROADCAST="10.42.7.63"     GATEWAY="10.42.7.1"     ;; esac 

This configuration applies to any PCMCIA network card that happens to be placed in slot 0. To make the configuration adaptable to a laptop that needs to establish network configuration between home and work, set up the network.opts file:

 case "$ADDRESS" in yourjob,0,*,*)     INFO="Work network setup"     IPADDR="10.1.1.200"     NETMASK="255.255.255.0"     NETWORK="10.1.1.0"     BROADCAST="10.1.1.255"     GATEWAY="10.1.1.1"     ;; home,0,*,*)     INFO="Home network settings"     DHCP=Y esac 

With this setup, you can switch between the static IP address assigned by your employer and the DHCP address you receive at home from your ADSL or cable router. To switch to the home settings, run the following command:

 #  cardctl scheme home  

The scheme is persistent after rebooting. This may be a problem if you shut down your system at home and bring it up at work, and you are still using your home network and wireless settings.

You can manually edit your lilo.conf so that the PCMCIA scheme is passed from LILO to the system init as a variable. Here is a lilo.conf that shows two different schemes:

 root = /dev/hda1 read-only image = /boot/vmlinuz-2.4.22   label  = home   append = "SCHEME=home" image = /boot/vmlinuz-2.4.22   label  = work   append = "SCHEME=yourjob" 

The /etc/pcmcia/wireless.opts file can be handled in a similar manner as network.opts . Again, the wireless.opts file accepts a large number of parameters, and you should read through the Wireless HOWTO before starting:

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/#howto

Also, read through the default /etc/pcmcia/wireless.opts file before making any changes. Back up the file before you start editing:

 /etc/pcmcia#  cp wireless.opts wireless.opts.orig  

Here is a sample of a configured wireless.opts file that sets an ESSID of home and a scheme of home :

 case "$ADDRESS" in     home,0,*,*)     INFO="Home wireless setup"     ESSID="home"     MODE="managed"     RATE="auto"     ;; esac 

The fields of interest are the ESSID, the mode, the channel, and the rate. The ESSID can be set either to the correct case-sensitive ESSID from the needed access point or to any , which allows the card to associate with any wireless network it finds.


For most cards, the mode can be set to managed or to ad-hoc . Managed mode is the 802.11 infrastructure mode, which means your card is a client to an access point. Ad-hoc mode can be used to communicate directly between two computers. Many cards support a third "monitor" mode that can be used to monitor wireless traffic. This mode is covered in Chapter 3. Finally, if you have a Prism or Atheros-based card, a fourth "master" mode can be used to let your card act as an access point (see Chapter 6).

Setting the rate allows you to determine the network speed your wireless card uses. For 802.11b cards, the valid rates are 1MB, 2MB, 5.5MB, 11MB, and auto. Setting this to any of the numerical values locks your card into that rate, and it transmits and receives at no other rate. If you want the card to automatically choose a rate up to a particular limit, use the desired rate along with auto. For example, choosing "5.5MB auto" chooses automatically 1MB, 2MB, or 5.5MB, depending on the amount of available signal. You may want to force a rate (or range of rates) if you are operating in an area with marginal coverage. Locking in a lower rate can sometimes lead to better performance than auto if the card is continually renegotiating the data rate.

The channel setting is not always needed, particularly if you have ESSID="any ". However, if you are in a noisy wireless environment with multiple access points, you may wish to set the ESSID and the channel to ensure that your card does not associate with other access points.

Building on the use of a scheme, here is an expanded wireless.opts that provides configuration for both home and work:

 case "$ADDRESS" in     home,0,*,*)     INFO="Home wireless setup"     ESSID="home"     MODE="managed"     CHANNEL="11"     RATE="auto"     ;; yourjob,0,*,*)     INFO="Work wireless setup"     ESSID="BigCorp"     MODE="managed"     CHANNEL="4"     RATE="auto"     KEY="s:bigsecret" esac 

Note that the work setup has another field: KEY="s:bigsecret ". "bigsecret" is the Wired Equivalent Privacy (WEP) key, and it is used to encrypt traffic between the client network card and an access point. WEP, its uses, and its weaknesses are covered in Chapter 4.

Debian Network Device Configuration

Debian users have an alternate method of configuring their network devices, including any wireless PCMCIA devices. Rather than relying on the /etc/pcmcia/network.opts and /etc/pcmcia/wireless.opts , all options are set using /etc/network/interfaces .

Any PCMCIA device you wish to configure with the /etc/network/interfaces file should not be marked as "auto." Debian will try to configure these interfaces before PCMCIA support is started, and the network configuration will fail.

The interfaces file is responsible for setting TCP/IP settings for any network interfaces configured in Debian. A sample entry defining a static IP address would look like this:

 iface wlan0 inet static  address 192.168.1.2  network 192.168.1.0  netmask 255.255.255.0  broadcast 192.168.1.255  gateway 192.168.1.l 

If you install the wireless-tools package via apt-get , rather than compiling from source, Debian adds hooks to the interfaces file to support new option statements. These options take the form of:

 wireless_<   function   > <   value   > 

When the interface is brought up during the boot process, these options result in the execution of the following Wireless Tools command:

 iwconfig <   interface   > <   function   > <   value   > 

Using this method, any command that is recognized by iwconfig , except for "Nickname," can be entered in /etc/network/interfaces and passed to the wireless card when it is initialized . To expand on the previous sample entry, here is an expanded entry that sets various wireless parameters:

 iface wlan0 inet static  address 192.168.1.2  network 192.168.1.0  netmask 255.255.255.0  broadcast 192.168.1.255  gateway 192.168.1.1  wireless_essid NoCat  wireless_mode Managed 

2.3.4 Installing the Wireless Tools

The Linux Wireless Tools and their companion API, the Wireless Extensions, are both the work of Jean Tourrilhes at Hewlett Packard, who maintains an excellent web page full of useful information for Linux and wireless LANs at http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/.

While the Wireless Tools and Extensions are not the only methods of configuring and using wireless network cards under Linux, they are the most common and are discussed in this chapter.

2.3.4.1 Wireless Extensions

To use the Wireless Tools, you must have a kernel and drivers with the Wireless Extensions. Fortunately, most kernels since 2.2.14 have included the wireless.h that defines Wireless Extensions in the kernel. In order for the Wireless Extensions to be included in the kernel, you must make sure that the CONFIG_NET_RADIO option is enabled. If you built your kernel following the instructions earlier in the chapter, your kernel should be built properly with the Wireless Extensions.

Table 2-1 shows what version of the Wireless Extensions your kernel should support (see Jean Tourrilhes's web page for the most recent information).

Table 2-1. Wireless Extensions support in Linux kernels

Version

Kernel

Features

WE-9

2.2.14, 2.3.30

Basic 802.11b support

WE-10

2.2.19, 2.4.0

Add TxPower setting

WE-11

2.4.4

Driver version check, retry setting

WE-12

2.4.13

Additional statistics

WE-13

2.4.19, 2.5.3

New driver API

WE-14

2.4.20, 2.5.7

Wireless Scanning, Wireless Events

WE-15

2.4.21, 2.5.37

Enhanced iwpriv support

WE-16

2.4.23, 2.6

802.11a/802.11g fixes, Enhanced iwspy support

The Wireless Extensions Version 16 is used for all the examples that use the 2.4.23 kernel. While there are patches to upgrade older kernels to later versions of the Wireless Extensions, it is not recommended, as many of the changes in wireless.h are dependent on specific kernel features and were not tested in older kernel versions.

2.3.4.2 Compiling the Wireless Tools

Now that you know the version of the Wireless Extensions that your kernel includes, you should get the latest version of the Wireless Tools. At the time of this writing, the latest stable version is 26 and can be obtained from the pcmcia-cs web site:

http://pcmcia-cs.sourceforge.net/ftp/ contrib /wireless_tools.26.tar.gz

If you don't want to compile from source, you can install a binary package. Debian users can install the Wireless Tools as a package using apt-get install wireless-tools . RedHat and Mandrake users can install the wireless-tools RPM from the installation CDs. Other distributions should have a similarly named package.


Your best option is to download the source code from the aforementioned link and build the Wireless Tools for your exact version of the Wireless Extensions in your kernel. If you install a package version, it may have been compiled against a different version of the Wireless Extensions. When this happens, every time you use one of the Wireless Tools, you will see this error message:

 Warning: Driver for device wlan0 has been compiled with version 14 of Wireless Extension, while this program is using version 15.  Some things may be broken... 

As the error message states, if you are using a version of the Wireless Tools that has been compiled with a previous version of the Wireless Extensions, some features may not work. Looking at Table 2-1, you can see that if you use a version of the Wireless Tools that had been compiled against Version 13 of the Wireless Extensions, you would not be able to use the Wireless Scanning in Version 14, regardless of the version of the Wireless Extensions in your kernel.

To successfully compile the Wireless Tools, you should need only a working compiler environment and a kernel with CONFIG_NET_RADIO enabled. PCMCIA support is optional but obviously required if your wireless card is a PCMCIA card. To really use the tools, you definitely need a wireless driver that supports the Wireless Extensions. Most Linux drivers do. Consult Jean Tourrilhes's web page if you have questions about a specific driver. Of the drivers covered in this chapter, only the wlan-ng driver does not support the Wireless Extensions.

To begin compiling the package, download the wireless_tools.26.tar.gz file into the /usr/src directory. Unpack the tar.gz file and change into the top-level directory:

 #  tar xzvf  wireless_tools.26.tar.gz #  cd  wireless_tools.26 

There isn't any configuration to do. As Jean Tourrilhes says in the INSTALL text file, "in theory a `make' should suffice to create the tools." You should be able to:

 #  make  #  make install  

One potential problem you may run into: there are compilation issues with certain kernel and libc combinations. If you receive the error "Your kernel/libc combination is not supported," it means some code hacking is required. For your purposes, you are better off installing a packaged version from your distribution.

2.3.5 Using the Wireless Tools

You now have the Wireless Tools compiled and installed in /usr/local/sbin . There are four binary executables included with the Wireless Tools. All four Wireless Tools pull information from /proc/net/wireless , which is created only when your kernel is compiled with the Wireless Extensions.

2.3.5.1 iwconfig

This is the tool you use to configure the basic operating parameters of your wireless card. It is also the tool that is called during the boot process to configure your card based on settings in /etc/pcmcia/wireless.opts .

Called without any arguments, iwconfig displays current wireless settings for any wireless cards in the system. A typical example would look something like this:

 lo        no wireless extensions. eth0      no wireless extensions. wlan0     IEEE 802.11-b  ESSID:"NoCat-Grandview"  Nickname:"airhead"           Mode:Managed Frequency:2.462GHz             Access Point: 00:02:6F:04:78:7E           Bit Rate:11Mb/s   Tx-Power=24 dBm   Sensitivity=1/3           Retry min limit:8   RTS thr:off   Fragment thr:off           Encryption key:off           Power Management:off           Link Quality:40/92  Signal level:-77 dBm             Noise level:-100 dBm           Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0           Tx excessive retries:5293  Invalid misc:86372              Missed beacon:0 

If you have multiple wireless network cards and you don't wish to see the "no wireless extensions" message each time you run iwconfig , make sure to specify the interface:

 $  iwconfig wlan0  

This only shows the configuration for the specified network card.

As you can see, there are quite a number of parameters that iwconfig can set. Not everything can be changed, however. Starting with Link Quality , the output is taken from /proc/net/wireless and consists of read-only statistics.

All of these parameters, settings, and statistics are device- and driver- dependent. Each wireless driver is going to write different things to /proc/net/wireless , and each driver supports commands from the Wireless Tools differently. For example, if you use an Orinoco card with the orinoco_cs wireless driver, your options for "Mode" are much more limited than if you use a Prism II-based card with the hostap_cs driver.

Let's step through the available iwconfig parameters. In the following examples, we use the eth1 interface, but it may be something different, such as wlan0 in the hostap_cs driver or ath0 in the madwifi driver:


essid < name >

Sets the network name or SSID to which the wireless card connects. A useful option is to set the name to any , which allows the card to connect to any available wireless network:

 #  iwconfig eth1 essid NoCat  #  iwconfig eth1 essid any  

freq or channel

Sets the operating frequency or channel of the wireless card. channel accepts a number in the range of 1-11 (U.S.) or 1-14 (E.U.). freq accepts the frequency in Hz. You should enter the exact frequency, such as 2.462 for channel 11. You can also enter the frequency with the suffix of G: 2.46G for channel 11:

 #  iwconfig eth1 channel 6  #  iwconfig eth1 freq 2.437  #  iwconfig eth1 freq 2.43G  

mode

Sets the operating mode of the wireless card. There are different options depending on your wireless card and driver. Most cards and drivers under Linux support ad-hoc mode for communicating with another node, without any access points. The most common mode is managed , which allows the wireless card to connect as a client to an access point. One advanced mode is master , which is supported in the hostap and madwifi drivers, and makes the card into a software-controlled access point. Another advanced mode is monitor , which turns the wireless card into a passive receiver that can only receive packets:

 #  iwconfig eth1 mode managed  #  iwconfig eth1 mode ad-hoc  

ap

Enters a hardware address of a specific access point, which forces the card to associate with that access point. By default, if the connection quality degrades or is unusable, the card defaults back to automatic mode, where the card finds the best access point in range. You can defeat this by using the option off to disable automatic mode. any or auto enables automatic mode.

 #  iwconfig eth1 ap 00:02:2d:53:66:19  #  iwconfig eth1 ap off  #  iwconfig eth1 ap auto  

sens

Sets the sensitivity threshold of the wireless card. The card does not receive any signal lower than this level. This avoids background noise. Positive values are assumed to be the raw value used by the hardware, or a percentage. Negative values are assumed to be dBm. Again, the settings are dependent on the hardware of the wireless card. Prism and Orinoco cards seem to treat only values of 1-3 as valid sensitivity settings. Depending on your hardware, this parameter may also control the defer threshold (the lowest signal level for which the channel is considered busy) and the handover threshold (the lowest signal level where the card stays associated with an access point).

 #  iwconfig eth1 sens -80  

rate

Sets the bit-rate in bits/second. Once again the available options depend on your wireless card. The value of the option must be the exact bitrate number or should have M appended to the end of the number. auto is the default setting for most cards and falls back to lower bit-rates if there is noise.

 #  iwconfig eth1 rate auto  #  iwconfig eth1 rate 11M  # (802.11b) #  iwconfig eth1 rate 54M  # (802.11a/g) 

rts

RTS/CTS adds a handshake before each packet transmission to make sure that the channel is clear. This adds quite a bit of overhead and decreases the potential bandwidth. However, it can result in increased performance in the case of hidden nodes or large numbers of active nodes. Set a packet size that determines the minimum packet size threshold for enabling RTS/CTS, auto to have the driver automatically perform RTC/CTS, or off to disable:

 #  iwconfig eth1 rts 250  #  iwconfig eth1 rts auto  #  iwconfig eth1 rts off  

frag

Sets the fragmentation threshold. This allows the card to split a packet into smaller packet fragments to transmit. As with rts , this adds overhead and reduces the available bandwidth, but in very noisy environments, it reduces the amount of errors and tries to send packets again. As with rts , you set a packet size that determines the minimum packet size for determining when fragmentation should be enabled. You can also set auto to have the driver automatically perform fragmentation or off to disable fragmentation.

 #  iwconfig eth1 frag 512  #  iwconfig eth1 frag auto  #  iwconfig eth1 frag off  

nick

Sets the nickname or station name of the wireless card. Most 802.11 devices define this parameter, but it is completely optional and doesn't affect performance or operation at all. Some diagnostic tools may use it.

 #  iwconfig eth1 nick "Network God"  

key or enc

Sets the encryption mode and keys for the wireless card. on and off enable and disable encryption, respectively. Encryption keys can be entered as hex digits, with or without separation dashes, or ASCII strings can be entered in the format s:password . Generate an index of keys by appending an index number in brackets ( [ ]) to the key when it is entered. Once you have multiple keys in the index, change keys by simply passing the index number as the option. Two modes are available: open and restricted . open accepts nonencrypted traffic, while restricted accepts only encrypted packets.

 #  iwconfig eth1 enc on  #  iwconfig eth1 key 0a12fc132  #  iwconfig eth1 key s:supersecret [2]  #  iwconfig eth1 key [2] restricted  

power

Sets power management modes and parameters. on and off enable and disable power management, respectively.


txpower

For cards that support multiple transmit powers, this sets the transmit power in dBm. on and off enable and disable radio transmissions entirely. auto enables automatic power selection if that feature is available. If the entry is followed by "mW," the value automatically is converted to dBm. Geeky math note: if W is the power in watts, the power (P) in dBm is P = 30 + 10.log(W).

 #  iwconfig eth1 txpower 30  #  iwconfig eth1 txpower 200mw  #  iwconfig eth1 txpower auto  #  iwconfig eth1 txpower off  

retry

For cards that support MAC retransmissions, this allows you to change the parameters of the retry. You can set the maximum number of retries with limit and an absolute value. The maximum length of time the MAC should retry is set with lifetime , in seconds. You can append "m" or "u" to specify milliseconds or microseconds respectively. limit and lifetime can also be modified by the use of min or max , which allows you to set the upper and lower boundaries of limit and lifetime .

 #  iwconfig eth1 retry 16  #  iwconfig eth1 retry lifetime 300m  #  iwconfig eth1 retry min limit 8  #  iwconfig eth1 retry max lifetime 500m  

--version

Displays the version of iwlist and the Wireless Extensions:

 #  iwconfig --version  iwconfig  Version 25           Compatible with Wireless Extension v15 or earlier,           Currently compiled with Wireless Extension v15.     wlan0     Recommend Wireless Extension v13 or later,           Currently compiled with Wireless Extension v14. 

To summarize: iwconfig allows you to change the configuration of your wireless network card on the fly. All of the options supported by iwconfig can be set in /etc/pcmcia/wireless.opts , and when the PCMCIA subsystem is initialized, these options are executed as the card is configured.

2.3.5.2 iwlist

This is mainly used for showing lists of parameters that the current wireless card supports. However, it does have one very useful feature that is not a list of parameters.

If you would like to see a list of access points available for your wireless card, iwlist is your ticket. You won't have to install other network-scanning utilities like Kismet (covered in Chapter 3). Not all card drivers support this option. For instance, the orinoco_cs driver does not support scanning. To initiate scanning, this command must be run with root access:

 #  iwlist eth1 scan  

Here is a sample of th output you might expect:

 wlan0     Scan completed :           Cell 01 - Address: 00:02:6F:04:78:7E                     ESSID:"NoCat"                     Mode:Managed                     Frequency:2.462GHz                     Quality:0/92  Signal level:-64 dBm  Noise level:-100 dBm                     Encryption key:off                     Bit Rate:1Mb/s                     Bit Rate:2Mb/s                     Bit Rate:5.5Mb/s                     Bit Rate:11Mb/s 

If you are in an area with multiple access points, you should see "Cell" entries for each access point, with specific information on signal and noise level. This is a very useful base tool for finding access points in an unfamiliar environment, or even for baselining your wireless network infrastructure.

Aside from this, iwlist serves as a query tool to determine what features your wireless card supports. Let's step through the available iwlist queries:


freq

Displays the list of available radio frequencies and the number of defined radio channels. It also displays the currently used radio channel. For a U.S. user, typical output from this command would be:

 $  iwlist wlan0 freq  wlan0     14 channels in total; available frequencies :           Channel 01 : 2.412 GHz           Channel 02 : 2.417 GHz           Channel 03 : 2.422 GHz           Channel 04 : 2.427 GHz           Channel 05 : 2.432 GHz           Channel 06 : 2.437 GHz           Channel 07 : 2.442 GHz           Channel 08 : 2.447 GHz           Channel 09 : 2.452 GHz           Channel 10 : 2.457 GHz           Channel 11 : 2.462 GHz           Current Frequency:2.462GHz (channel 11) 

ap or peers

This feature is deprecated in favor of the scan feature, previously mentioned. Most current drivers do not support this feature. However, some drivers may use this command to return a specific list of peers associated with the wireless card.


rate

Lists the bit-rates supported by the card and the current bit-rate in use:

 $  iwlist wlan0 rate  wlan0     4 available bit-rates :           1Mb/s           2Mb/s           5.5Mb/s           11Mb/s           Current Bit Rate:11Mb/s 

key or enc

Lists the encryption key size supported, the available keys in the wireless card, and the current key in use:

 $  iwlist wlan0 key  wlan0     2 key sizes : 40, 104bits           4 keys available :                 [1]: off                 [2]: off                 [3]: off                 [4]: off           Current Transmit Key: [0] 

txpower

Lists the various transmit powers available on the wireless card. This feature appears to be broken, at least with respect to Wireless Extensions 15 and a Prism card using the hostap driver.


retry

Lists the transmit retry limits and lifetime:

 $  iwlist wlan0 retry  wlan0     Fixed limit    ;  min limit:0                             max limit:255           Current mode:on                   min limit:8 max limit:5 

--version

Displays the version of iwlist and the Wireless Extensions:

 $  iwlist --version  iwlist    Version 25           Compatible with Wireless Extension v15 or earlier,           Currently compiled with Wireless Extension v15.     wlan0     Recommend Wireless Extension v13 or later,           Currently compiled with Wireless Extension v14. 
2.3.5.3 iwspy

This is a useful tool that shows you quality-of-link information for one or many nodes in a wireless network. The information is taken from /proc/net/wireless , but when running iwspy , the statistics are updated each time a packet is received from the remote node. This does add some driver overhead, which means that local performance on the machine running iwspy is degraded. Note that different drivers may partially support iwspy or may not support it at all.

In the most basic mode, simply run iwspy interface :

 $  iwspy wlan1  wlan1     Statistics collected:     00:02:6F:03:FE:65 : Quality:42/92  Signal level:-90 dBm       Noise level:-98 dBm     00:02:2D:04:EB:15 : Quality:31/92  Signal level:-94 dBm       Noise level:-98 dBm 

As in the previous example, you should see a MAC address for every remote station, along with quality, signal level, and noise level statistics.

To start collecting statistics for a specific node, invoke iwspy with a DNS name, an IP, or hardware address:

 $  iwspy wlan1 192.168.0.1  

Then, when you invoke iwspy again for that interface, you see not only the current statistics for the remote node, but a set of averages as well:

 $  iwspy   wlan1  wlan1      Statistics collected:     00:02:6F:01:6A:02 : Quality:18/92  Signal level:-82 dBm       Noise level:-100 dBm (updated)     typical/average   : Quality:36/92  Signal level:-62 dBm       Noise level:-98 dBm 

You can have iwspy monitor up to eight addresses simply by passing it multiple DNS names , IP, or hardware addresses on the command line:

 $  iwspy wlan1 192.168.0.1 test.foobarus.com notebook.foobarus.com  

Again, when you invoke iwspy for that interface, you see current statistics for each remote node plus an average across all three nodes.

If you are already monitoring three remote nodes and run iwspy again with a fourth IP address to monitor, iwspy will replace the monitoring of your existing three nodes with monitoring of the new IP address. To avoid this, use the + sign before the IP address on the command line:

 $  iwspy wlan1 + 192.168.0.15  

This appends the new address to your existing list of addresses that are already being monitored .

To disable any iwspy statistic collection you may have started, simply turn it off:

 $  iwspy wlan1 off  

Two more useful commands in iwspy let you set high and low signal strength thresholds for wireless events. setthr < low / high > sets the thresholds, and if an address monitored with iwspy goes higher or lower than the thresholds, a wireless event is generated:

 $  iwspy wlan1 setthr 40 80  

This means that you can monitor link status on multiple connections without having to continually run iwspy .

To show what the threshold has been set to, type the following:

 $  iwspy wlan1 getthr  
2.3.5.4 iwpriv

This tool allows you to configure private wireless options ”in other words, options that are limited to a single wireless driver. This is different than iwconfig , which deals with generic settings that are applicable to all wireless cards.

Called without any arguments, iwpriv returns a list of available private commands. On a Prism II-based Senao 200 mW card, the following list is returned:

 wlan0     Available private ioctl :           monitor          (8BE4) : set   1 int   & get   0           readmif          (8BE3) : set   1 byte  & get   1 byte           writemif         (8BE2) : set   2 byte  & get   0           reset            (8BE6) : set   1 int   & get   0           inquire          (8BE8) : set   1 int   & get   0           set_rid_word     (8BEE) : set   2 int   & get   0           maccmd           (8BF0) : set   1 int   & get   0           wds_add          (8BEA) : set  18 char  & get   0           wds_del          (8BEC) : set  18 char  & get   0           addmac           (8BF2) : set  18 char  & get   0           delmac           (8BF4) : set  18 char  & get   0           kickmac          (8BF6) : set  18 char  & get   0           prism2_param     (8BE0) : set   2 int   & get   0           getprism2_param  (8BE1) : set   1 int   & get   1 int 

This list shows that there are quite a few private options that can be set using iwpriv on a Prism II card. One option is WDS, the Wireless Distribution System, which is covered in Chapter 6. Most of the private commands are hardware- and driver-specific.

Many cards support some types of iwpriv reset command. The orinoco_cs driver includes card_reset and force_reset options for iwpriv .

 <  Day Day Up  >  


Linux Unwired
Linux Unwired
ISBN: 0596005830
EAN: 2147483647
Year: 2004
Pages: 100

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net