< Day Day Up > |
To use a Wi-Fi card on your Linux system, you need several things:
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:
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.
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 DriversWe 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:
2.3.2 Configuring and Compiling Your KernelThere are a number of reasons why you should consider compiling your own Linux kernel from source:
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:
To configure and compile a Linux kernel, you must obtain the following items:
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:
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 .
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 racesAssuming 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.
Figure 2-2. Initial menu from make menuconfig
Figure 2-3. Initial menu from make xconfigFor 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 SubsystemAs 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.
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:
2.3.3.1 2.4 kernels and kernel tree PCMCIANote 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 subsystemTo 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 configurationPCMCIA 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:
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:
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
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.
2.3.4 Installing the Wireless ToolsThe 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 ExtensionsTo 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
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 ToolsNow 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:
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 ToolsYou 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 iwconfigThis 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:
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 iwlistThis 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:
2.3.5.3 iwspyThis 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 iwprivThis 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 > |