Wireless LANs in use

Jean Tourrilhes

25 July 07

"Why can't I receive the FM on my Wireless LAN ?"

Then, I will explain some of the difference of Wireless LANs compared to wired technology from the user point of view and why it reacts sometime differently. For more curious people, see the section 5.

1 Choice and selection of a Wireless LAN

Most Wireless LANs are designed to work well in most configurations, but my experience tells that some Wireless LANs or some environment may be capricious. Of course, the vendor won't advertise this, so it's your responsibility to check that the Wireless LAN is working with your particular setup. If you intend to cover a large range, test as many physical locations and combinations as possible to avoid surprises. Know the limits of your hardware.

The performance of different Wireless LANs may vary widely, depending on may factors. The throughput of two Wireless LANs advertising the same bit rate may vary by a factor 5 (I won't give the names). Range also can have wide variations, even between similar cards. So, be warned and benchmark your Wireless LAN...

If you are not happy with your choice of Wireless LAN, don't hesitate and return it to where you bough it for a refund.

2 Features of the hardware

Then, the second issue is the form factor, and the interface use to connect the card to your PC. Most cards nowadays are in Cardbus form factor and USB form factor, most vendors offer as well PCI or Mini-PCI versions of their cards. Older cards may come in ISA, Pcmcia (16 bits) and CF form factor. In some cases, it is possible to plug a Pcmcia or Cardbus card in a desktop using ISA-to-Pcmcia or PCI-to-Cardbus bridges, but those are not always properly supported. I've seen some old cards in PC104 form factor (for embedded applications).

Often, people do wonder about Access Points and residential gateways and if they need some for their network. In most cases, the Access Point is a bridge and allow to connect the wireless network to an Ethernet backbone, whereas the Residential Gateway connect it to an ISP (via dialup/cable/DSL), and those two kind of products are usually not fully interchangeable. However, most Wireless LAN cards work in ad-hoc mode (so without Access Point), and a Linux box can offer connectivity to other networks (routing+proxy ARP, or masquerading).

For people who plan to establish point to point links, they will likely need the card to offer a connector for an external antenna. Quite often those connectors are small and not really standard. Of course, if the card doesn't offer such a connector, it's always possible to butcher it...

Then, you may care about all the usual performance characteristics, such as speed, range, and power consumption. However, be aware that it's quite difficult to compare products, for the speed read my various comments about overhead and benchmarking, and for range pay mostly attention to the transmit power and the sensitivity.

Finally, each implementation may offer more or less wireless parameters. Having those parameters will allow to tune the card for specific environments and configurations. With that, you probably want some deployment and diagnostic tools from the vendor...

Personally, I believe that the number one consideration in making your choice should be the range (coverage), and that raw speed is the least important of the things mentioned above. If you need speed, you should use Gigabit Ethernet. Wireless enables mobility, and you want to make sure to retain network connection wherever you are.

3 Interoperability

For most of the old hardware, and for all the proprietary products, interoperability is none. In other word, those products communicate only with products from the same vendor. The risk for you is that you are locked with this vendor to upgrade your network. That is still OK if the vendor is strong and has been around in the business for a long time.

The only two standards that have been demonstrated to be interoperable across different implementations are 802.11-FH and 802.11-DS (other standards may be interoperable due to a single implementation). I must there applaud the various vendors which have gone through great pain to make sure that their hardware was playing nice with others and fixing their interoperability problems. Note that 802.11-FH products are not interoperable with 802.11-DS products, and vice versa, so you can only mix products of the same kind of 802.11.

As the 802.11-b specification is just a simple extension of 802.11-DS (adding 5.5 and 11 Mb/s speeds), all products interoperate at least at 2 Mb/s (802.11-DS mode), and all products I have seen also interoperate at 11 Mb/s.

In general, all proprietary extensions of 802.11 have poor interoperability, they will only work if all devices are from the same vendor, however those devices will interoperate at standard speeds with other products. 802.11+ is a semi-proprietary extension of 802.11b, adding the 22 Mb/s speed. All products are based on the same chipset, and they also interoperate with 802.11b products.

The 802.11g standard is a non straightforward extension of 802.11b. Early products from different vendors did not always interoperate properly with each other at higher speeds (but will interoperate at 802.11b speeds), and sometime they did not interoperate with 802.11b products and may actually disrupt 802.11b networks. Recent 802.11g products are much better, except for Ad-Hoc mode which is usually poorly supported.

Early 802.11a products (5 GHz) are interoperable, because they were based on the exact same chipset, recent products have good interoperability. They do not interoperate with 802.11b products, because using a different frequency band, but some products doing both 802.11b and 802.11a are available.

Pre-802.11n products have a poor track record at interoperability so far, however it will get better as we get closer to the final standard.

Other standards (such as HiperLan, HiperLan2 and SWAP) are interoperable in theory. As there is very few vendors using those standards (or even none) and the products are often too recent, we can't say much about interoperability. Note that compliance doesn't mean interoperability and vice versa...

Note that in some cases, the Linux driver of a device doesn't implement all the features of the corresponding Windows driver (typically security), limiting the interoperability.

4 Which vendor to select

The first problems is that there are now lot's of different vendors and brands, and most I've never heard off (and they tend to be the cheapest, so the most popular). It's almost impossible to track down all of them. Fortunately, there is only a limited number of chipset, so most of those vendors sell the same hardware (or minor derivation) and there is a good probability that it works with an existing Linux driver.

The other issue is that some vendors use different chipsets in their various products, so some of their cards might be supported and some might not be. They can switch their entire product line to a new chipset pretty quickly, so a "brand" is not a safe bet. Some vendor even sell different chipset under the same model number (example D-Link and Linksys), making it very difficult to know in advance if the card is supported or not.

In the past, most of the "generic" brands selling 802.11b cards were using the Intersil PrismII chipset, which is well supported under Linux (various drivers), so it was not a problem. A lot of them have recently moved to non-supported chipset. Plain 802.11g cards are nowadays usually supported, but in most case require work to get the driver going. Laptop with Centrino cards are a very good choice. It's usually easy to identify Atheros cards, they usually advertise SuperG and 108 Mb/s. Pre-802.11n cards are usually not supported.

There are various hardware surveys that attempt to capture the latest list of compatible cards (see Wireless Howto front page). You can also search the various mailing list archives and the web for information.

5 How to identify a card

If the card is an ISA card, you are usually out of luck.

If the card is a PCI card, you need to use the command "lspci" to display the card identification strings.

If the hardware is a USB dongle, you need to use the command "lsusb" to display the dongle identification strings. In some case, "lsusb" doesn't work (for example if usbfs is not mounted), and you can get the identification strings from the kernel log using "dmesg" (or in /var/log/messages).

If the card is a Cardbus card (32 bits Pcmcia), and if you are using kernel 2.6.X or kernel 2.4.X with the kernel Pcmcia subsystem, you need to use the command "lspci" to display the card identification strings. If the card is a Cardbus card (32 bits Pcmcia), and if you are using an older kernel with the standalone Pcmcia subsystem, you need to use the command "cardctl ident" display the card identification strings. Try both and see what comes out.

If the card is a true Pcmcia card (16 bits), and if you are using kernel 2.6.14 or later, you need to use the command "pccardctl ident" to display the card identification strings. If the card is a true Pcmcia card (16 bits), and if you are using an older kernel, you need to use the command "cardctl ident" display the card identification strings. Note that cardmgr will also write some identification strings in the message logs (/var/log/daemon.log) that may be different from the real card identification strings.

The card identification usually helps to identify the chipset inside the hardware, and in some other cases it does not, because the vendor has changed the identity. Once you have identified the chipset, it is usually straightforward to check if the hardware is supported and which driver to use.

Most Linux drivers knows about some of those card identifications, and will automatically bind to the hardware. It is usually simple to add new identification to a driver.

Jacek Pliszka recommend to get the FCC-ID written at the back of the hardware and to run it through the FCC database. He also recommend to check the Windows driver (both identification and file name) for some clues.

6 Wireless hardware compatibility

Most Wireless LAN vendors have tried to make things easy and offer product with an interface as similar as possible as Ethernet, and which work mostly the same way. So, a bit of background on Ethernet and the general Linux networking is welcomed (see below).

The operating system need a piece of software to interface to the hardware. That is the role of the driver. Basically, when Linux gives to the driver a packet to send, the driver have to copy the packet to the hardware and toggle the correct bits in the correct register on the card to send it. It is the same when the card generates an interrupt, the driver go and read the packet and give it to Linux. Of course, the driver needs to know about the specific hardware details and the specific operating system ways.

In conclusion, you must check first if the driver for your Wireless LAN exists (see previous section), because in many case it proves to be quite useful...

With Linux, you normally have to compile the driver source code, however most Linux distribution offer precompiled modules for the most popular drivers. There is usually two compilation options : drivers compiled staticaly in the kernel and as a module. If the driver is already in the kernel sources, the compilation is quite simple (you have to enable it in the kernel configuration, static or module). If it is in the Pcmcia package, you just need to install the package.

Otherwise, see the installation instructions coming with the driver which should detail the procedure to install it.

Once you've got the driver compiled and installed, you must tell your system about it. This involve getting the driver to load (see section 9), wireless configuration (see section 10) and network configuration (see section 12).

8 Useful Linux related readings

For non-removable cards, things are simpler. If the driver is compiled staticaly in the kernel, it will be loaded at boot time. If it's a module, you can use Hotplug or udev to automatically load the driver, or you can load it as needed using /etc/modules.conf (see below).

Some older drivers (typically ISA) may load only with some required driver parameters. Those parameters usually allow to specify the base address and interrupt of the hardware to avoid scanning, but also might be used for multi-device configuration or wireless specific parameters (see below). Note that for all modern Plug-and-Play cards (PCI), those extra parameters are no longer necessary, as the system figure things by itself, so you can omit them (or set them to 0).

A lot of users are confused when it comes to set driver loading and parameters. As it is explained nowhere correctly, I disgress a bit and give you a few hints on how to load drivers with and without parameters...

For driver compiled staticaly in the kernel, the parameters are passed on the kernel command line. The syntax is "ether=irq,base,name" where base is the base address, irq the interrupt and name the device logical name (ex : eth0). The kernel command line is passed by lilo (or loadlin) itself, so in fact it means that you add in /etc/lilo.conf a line which look like this :

append="reboot=warm ether=0,0,eth1 ether=10,0x3E0,eth2 ether=11,0x390,eth3"

alias eth1 hp100
alias eth2 wavelan
options wavelan io=0x3E0,0x390 name=eth2,eth3 irq=10,11

However, you need to make sure the Pcmcia subsystem load the driver you desire, if there are multiple drivers bound to the same device you may end up with an unexpected driver. In this case, you need to edit the various Pcmcia config files (in /etc/pcmcia/ - grep is your friend).

For USB modules, you may use the HotPlug scripts. USB usually don't require any driver parameters, but again, you need to make sure the proper driver is loaded.

Before following up with the wireless configuration, you may want to make sure the driver is properly loaded, recognise the hardware and can initialise it. This can be done by checking the message logs (with dmesg).

10 Wireless configuration (more parameters to configure

Under Windows, the installation program usually opens a nice window and asks the user to enter these parameters, or sets them to a default value. Some drivers set those parameters in a permanent storage in the device (EEprom), so the Linux driver is able to reuse them. But, the current tendency is to scrap the EEprom and to use the Windows registry to save those parameters instead. Of course, the Linux driver can't retrieve the parameters in those conditions.

The Wireless Extensions (see next section) has been designed to simplify the process of setting those parameters under Linux by providing an unified interface across drivers, but not all drivers support (yet) the Wireless Extensions...

For the majority of drivers that support it, Wireless Extensions allow to change parameters at run time (using various tools - see my web pages) or be use at boot time or card insertion time through various initialisation scripts (this is usually distribution specific). Most Linux distributions nowadays fully integrate wireless configuration in their network configuration. The Wireless Tools package contains additional documentation on all this.

http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

The Wireless Tools also allow you to diagnose various basic problems (configuration not applied, not connected to the Access Point, invalid encryption key) and monitor the link. You need to make sure that the wireless link is established if you want your network setup to be successful.

Advanced security configuration, either 802.1x or WPA configuration, is done through wpa_supplicant or xsupplicant, which are daemons/applications handling those protocols. For those that prefer GUI, NetworkManager is a tools that allow to configure both the Wireless Extensions and wpa_supplicant graphically.

Drivers that don't use Wireless Extensions can use a variety of methods for configuration. Some have their own dedicated tools, some use a /proc interface and some use modules parameters, or a combination of these. The previous sections of the Wireless Howto should give you some hints on the subject.

In conclusion, you must read your documentation to know what parameters need to be set, what they are used for, and look the Linux driver documentation to know how to set them under Linux. See below for a suggested list of information sources.

It is usually quite a good idea to install the Wireless Lan first under some mainstream operating system with the official vendors driver and tools, to have a feeling of how the beast does work. You might also compare the performance before and after :-)

Once you've got all those new parameters set, your Wireless LAN should be up and running.11

8 Where to get information about your Wireless LAN configuration

• The official documentation that come with your product.
• Manufacturer web page and support.
• Linux driver source code, documentation (headers, man pages), maintainer.
• Documentation and man pages in the Wireless Tools package.
• Network configuration documentation for your specific Linux distribution

All this is exactly similar to standard Ethernet cards, and often specific to each distribution, so please check the relevant documentation. Note however that bridging very often won't work (see section section 14).

13 Wireless LAN deployment

To try to separate everyone out there, most products define some network identifier (802.11 calls it ESSID). This is a number or character string which is used to identify all the people wanting to be one the same logical network. Networks using different network identifiers still share the bandwidth, but are logically separate and ignore each other.

This situation is not totally ideal, so that's why usually you have some distinct channels (or frequencies, or hopping patterns). People on distinct channels use different part of the bandwidth, so don't interfere at all. If you want to install multiple independent networks in the same area, this is the way to go.

The Wireless LAN has only a limited range, so you may reach only device within that range. This is usually why you should define some cells where everybody is in range. If you want those cells to communicate or a node to move across cells, you should install an access point in each of those and configure those with the same network identifier (and add an Ethernet segment between the access points).

On the other hand, some time you just want to quickly set up a network between a group of nodes and don't want to build an infrastructure. Most Wireless LANs offer ad-hoc networking, allowing you to just do that (apart from TCP configuration).

Some network administrators are also a bit scared by security problem over the medium. The only solution is to use encryption.

14 Access Points, Home Gateways and Ethernet bridging

On the other hand, the Home Gateways allow a single cell to be connected to a WAN, like a modem, a cable modem or a DSL access. The set of features is quite different, and they offer NAT/masquerading and PPP configuration. Most Home Gateways also have an internal Ethernet switch and act as a MAC level bridge between their wireless and internal wired side.

The conventional Ethernet bridging method (promiscuous sniffing) doesn't work with most wireless LAN standard, because of the header encapsulation and the interactions with link layer retransmissions. In other word, most often, when you use a software bridge on a wireless LAN card (such as the Linux bridge on a 802.11 card), it doesn't work (moreover, quite often promiscuous is broken as well).

The driver could work around this restriction by creating its own MAC headers (802.11 headers instead of 802.3, and putting the right bits in the right place), but in fact most vendors don't provide the specification on how to this with their hardware (when they don't explicitely prevent it in hardware, to force you to buy their Access Points).

In other words, don't expect to use your Linux PC as a wireless bridge or wireless Access Points with most products out there, and forget about turning it into an Access Point. Of course, there is some exceptions that are listed in the driver descriptions (section 2).

The workaround is to set the wireless LAN in ad-hoc mode and to use other methods, such as routing, masquerading, IP bridging, ARP proxying...

15 Point to point links (connecting different LANs by wireless)

Some people have asked me question on how to use Wireless LANs to connect different LANs together using wireless technology, usually those LANs are in distant places (across the street). Most of the time, you can't use a Wireless LAN because you don't have a fully connected topology (some node can't see each other, it's more a set of point to point links) and you may need to use directional antennas to overcome the distance.

I've never personally tried this, but I see 2 ways to achieve this.

The first solution is to use Wireless Bridges. Each Wireless Bridge is connected to one of the LAN section and redirect the traffic over the air to the correct destination. There is many products on the market, they are a bit expensive but very flexible, transparent and optimised for the task.

The second is to use normal Wireless LAN cards, and to plug them in a router (for example a Linux PC). I recommend to use a Wireless LAN supporting RTS/CTS if you have more than one link, and to set them in ad-hoc mode (no access point). Each LAN segment must have a different IP subnet, and the wireless link must have it's own subnet (it can be a private subnet if you use masquerading). After much configuration of the routing tables of your network, you should be able to get it working.

Some people using the Aironet Arlan cards for this kind of application have made a very nice Arlan Wireless Routing Howto, and I believe it can apply to most other Wireless LANs as well :

http://www.rage.net/wireless/wireless-howto.html

Note that it is not always possible to use a bridging software on top of a Wireless LAN card, and that is why I do recommend routing (or proxy-ARP + IP forwarding). Setting the card in promiscuous mode won't give the behavior expected by the bridge, because of the interaction with MAC level retransmissions. Some drivers are clever enough, and by playing directly with the 802.11 headers (if the hardware allows it), they can allow bridging to work, but most drivers are not.

16 Performance (speed)

Most Wireless LANs products only specify their highest signalling rate (also called bitrate). The signalling rate is the speed the bits are send over the air (802.11b is up to 11 Mb/s, 802.11g is up to 54 Mb/s) and it doesn't account of all the overhead of the various protocols.

Most protocols have multiple rates and adapt the signalling rate depending on the quality of the link (for example 802.11b can run at 1, 2, 5.5 and 11 Mb/s). When the link is clear and reception is strong, it uses the fastest rate, but when there is noise/interference or the devices are further away, it downgrades to a more robust rate, which is slower. The throughput that you will get will depend on which rate you are using, for example the highest speed might be only usable in line of sight. The environment conditions constantly change, so most products adjust their rate continuously, and the bandwith available can be unpredictable.

The Wireless LAN protocols also have usually a higher overhead than their wired counterpart (such as Ethernet) because of some technological limitations and to improve the reliability and the coverage of the Wireless LAN (optimisation trade-offs). Wireless protocols have a lot more protocol overhead, such as contention, large headers, encryption, management frames... Retransmissions are needed to overcome various radio conditions. Part of the protocol overhead is fixed and does not scale with the bit rate, which means that at the highest rate this overhead is becoming proportionally larger. At 11 Mb/s the TCP throughput can be almost reduced to 50%.

17 Reliability

The propagation of radio transmissions is influenced by many factors. Walls and floors tend to decrease and reflect the signal, and background noise make it more difficult to extract. The channel quality vary quite a lot over the time (fading).

Depending on the quality of reception, the error rate will change (forcing packet retransmissions), or the system may switch to a more robust (and slower) mode (fragmentation or modulation), so the actual throughput will vary from good to nothing.

Because of the way radio transmission are affected by the environment, it is quite difficult to predict the comportment of the system and to define a range. You will have some good, fair and bad area/period, the closer you are the more likely you are to be in a good one.

19 Mobility

Of course, this mobility is limited by the range of the Wireless LAN. To extend the range, you must cover the area with access points, which very often include roaming : you switch transparently to the closer access point which provide you a connection to the rest of the world and nodes out of range.

Note that most cheap Access Point don't include roaming (to force you to buy the more expensive Access Point version), and that Access Points of different vendors usually don't fully interoperate (the Access Points don't talk to each other).

If you want to move across IP subnets, this is time to try Mobile IP :-)

20 Security and Privacy

First of all, any attack on a Wireless LAN will be necessary local (physical proximity), because of the limited range of radio. Most "attacks" will be your neighbor accidentally connecting to your network due to improper configuration. Directional antennas will allow the attacker to be further away than regular nodes, but only with line of sight. But this limit greatly the scope of the risk.

Wireless LAN, because they use digital transmissions, can not be listen to with a regular radio scanner. The only practical way to attack a Wireless LAN is to use another Wireless card compatible with it. The attacker may mostly try to do two things, snoop on your communications (for example to read the e-mail you are sending) or access your resources (for example your access to the Internet).

For most users, the network identifier (ESSID) will be enough protection against casual users : other people can't accidentally join your network by mistake, unless they guess the correct network identifier or really try to attack you. Obviously, you should change the default network identifier, and most products allow you to hide it, which you should.

Some people are more concerned about those issues or may want to increase the security of their system. Most Wireless LANs offer MAC level encryption. There is different levels of encryption, and not all security protocols are equal. A simple encryption like WEP was designed to offer security equivalent to a having a shared Ethernet cable (i.e. not much). Complex encryption like WPA are much more secure, and impossible to break-in in practice, but they are usually more complex to set up and manage. Finally, for high security, various techniques are available at the higher layers of the protocol stack.

The basis of all MAC level encryption scheme is that each packet transmitted over the network is individually encrypted with a secret key, and the card refuses unencrypted data or data encrypted with a different key. This encryption is totally transparent to the higher layer, everything is handled at the MAC layer, as opposed to VPN solutions that create encrypted tunnels at higher layers.

Simple encryption schemes, such as WEP, are widely available and supported, and are usually easy to set-up, the same encryption key is set up in the access point and all nodes of the network, no central authority is needed. However, these schemes are considered weak because they use a single key distributed to all nodes, don't have key management facility and lacks per-packet authentication. On top of that, the encryption algorithm, RC4, is not considered very strong. Over the years, various attacks have been found on WEP, the MAC level encryption scheme of 802.11, which illustrate that WEP is not more secure than what it was designed for (and probably less). In any case, enabling WEP is better than nothing, it can be seen as putting a "do not enter" sign on your network.

Various encryption schemes have been released for 802.11 to address the shortcomings of WEP. The initial version of 802.1x adds elaborated key management to WEP, and changes the WEP key frequently. Today, this is not considered very secure, because it is still based on WEP. WPA and WPA2 improve on 802.1x by having better key management and using AES instead of RC4. Those are considered state of the art and are beginning to be well supported and interoperable, but they are more complex to deploy and require a central authority (usually implemented in an Access Point or a Wireless Controller).

For higher level of security, I would advise to use a security solution independent of the wireless link (like IPsec or a regular VPN, see below). This separation of wireless and security has other advantages, for example the security solution can be updated independently of the hardware as needed, and hardware from different vendors can be mixed.

I would still argue that most home users don't really need security beyond preventing people accidentally joining their network. Most web site that you will access over wireless and that handle critical information already use SSL to encrypt those transactions, which is proven to be very secure, and there exist secure versions of POP or IMAP (still using SSL). Users that access remote Intranets most often already uses VPN software. So all critical transactions are often already protected, or easy to protect.

For those who need it, like if you are paranoid, your life depends on it, or if the wireless link is already behind a firewall, you need to set up a encrypted tunnel above the wireless link with a VPN protocol. Various VPN protocols can be used with Linux, such as IPsec, PPTP and SSH (IPsec considered is the ultimate security solution). You will need to setup a VPN gateway on the other side of the Access Points and the VPN software on every wireless device. That's usually complicated to setup, but that's the price for security.

21 Benchmarks

If you want to test the throughput of your device, you should use a tool called Netperf. You might want to submit your results in the database...

http://www.netperf.org/netperf/NetperfPage.html

22 Tuning

Most 802.11g and 802.11n Access Points have two modes, mixed mode and exclusive mode. Mixed mode makes sure that the Access Point interoperate well with legacy and older devices, but is slower than the exclusive mode. Obviously, you want all your devices to get the best performance, not a selected few, so you need to set the mode appropriate for your device mix.

Many vendors have proprietary extensions, that enable them to claim very high speeds. These extensions, especially channel bonding (wider channels), may confuse other devices, so in some cases you may want to turn them off.

Some vendors ship products with RTS/CTS disabled. This is the best setting if you have only two nodes, but when you have a fair number of nodes active at the same time, RTS/CTS can increase the performance. And of course, if you have hidden nodes, you can not get away without it...

Some vendors also tend to set the number of MAC retransmissions a bit low for my taste. If you use TCP, this might improve your performance slightly under good conditions, because TCP do its own retransmissions. However, all applications not using TCP (ping, RTP, NFS...) might suffer from the packet losses.

On a related note, you can play with the bit-rate setting of the card. Most cards nowadays include a rate-adaptation scheme, which adapt the bit-rate to the range : basically the card try transmitting at the highest rate and decrease the rate in case of packet losses. However, in configuration with large number of active nodes, packet losses also come from the contention process, so disabling this rate adaptation scheme (forcing the highest rate) can increase performance in some cases.

If you have interferers in the band, you might need to enable fragmentation (send smaller packet to fit between interferences) and to raise the sensibility (tell the card to ignore the noise). Of course, the best thing is to eliminate the interferer, if possible.

If you have different Access Points and have enabled roaming, you should also set carefully the roaming threshold, which is the point (in signal strength) at which the card search for a new Access Point. If you set it too low, the card will spend to much time with a non optimal AP (getting a poorer throughput), and if you set it too high the card will waste time searching for a new AP too often.

To finish, all this fine tuning and optimisation could/should be done in the card itself, not by the end user, the card itself has most of the information it needs to optimise those settings and the algorithms are not that complex (I describe some in my latest papers). This ensure that users automatically get the best performance in any condition. Most modern wireless hardware is now getting much better at doing this automatic tuning, and nowadays you need less and less to do any manual tuning (and actually tuning may be counter-productive in some cases).

next

Linux Wireless LAN Howto - jt@hpl.hp.com Converted to html from Frame Maker - 1 May 97 Updated 25 July 07 Copyright © 1996-2007 Jean Tourrilhes

Project hosted and sponsored by :