Chapter 3. Frequently Asked Questions

Depends on what you are used to. The card runs the radio at 2 megabits/second. The actual throughput doing FTP is about 140 kilobytes/second under optimum radio conditions. It is not unusual to see 80-90 with some cards in some environments. As a general rule, I find no difference in speed between linux<->linux, linux<->windows, and windows<->windows. Note that I am giving numbers only for the FTP protocol and they are in kiloBYTES/second. My 56k modem does about 4 kilobytes/sec and a cable modem on a good day is 120 kb/s. On the other hand, my 10baseT ethernet is good for about 1100 kb/s. So, unless you are accustomed to something better than your own private T1 line to the internet, the card is fast enough.

Version 1.67 contains patches from an alpha user who got it to work. It has been reported successful by several other alpha users. I know of no other architectures where it has even been attempted.

It works on at least several SMP machines. Reports of success or failure are welcome.

Yes. It works with the ISA adapter supplied by Raylink and Webgear. It has also been used with other ISA adapters. Basically, if card services works with the ISA adapter, then the wireless LAN card will work.

802.11 has two basic network types: adhoc and infrastructure. Adhoc networks are an arbitrary number of stations (usually notebooks) talking directly to each other. Infrastructure networks contain some number of stations all talking to an access point. The Aviator 2.4 is set up for adhoc networking, and the Aviator Pro is set up for infrastructure networking. The cards are the same in both cases, but are set up differently. Also, the cards for the aviator pro have newer firmware, which is the same firmware as the windows 2000 upgrade uses. This new firmware is not compatible with the old Aviator 2.4 firmware.

There are reasons to do either method. If you do significant traffic between notebooks in the house, then an adhoc network is better, because the stations talk directly to each other. In an infrastructure net, all traffic goes through the AP which means every packet from one wireless station to another has to be sent over the air twice - from the sender to the AP and from the AP to the receiver. So if you do file sharing between your wireless machines, it will be twice as fast with an adhoc network.

If on the other hand, you don't do much traffic between wireless stations, but mainly communicate with a wired station, or the internet, then both solutions are about the same for throughput. The access point does however support a power saving mode that isn't available in adhoc networks. Also, you can position it for optimum reception more easily than with a PC because you can hang it on the wall. Lastly, if your network is physically large, you can have multiple AP's and the stations will roam transparently from one to the next as the station moves.

Once upon a time, the 802.11 spec was written. They didn't specify what to do with the ethernet header, so some vendors encapsulated the whole ethernet packet inside the body of an 802.11 packet. Other vendors used a translation scheme which removed the ethernet header, because they don't have to send the addresses twice. They do have to add a SNAP header (8 bytes) in place of the 2 addresses (12 bytes) so they only saved 4 bytes, and made it more complex. Naturally, the more complex scheme was later adopted by the IEEE, and translation is becoming the norm. However, there are many older systems that only do encapsulation, so ray_cs supports both types.

Some users have reported that they were unable to connect to windows machines with translation on. Others have had no problem, so if it looks like the network is joined, but you can't ping, try translate=0 at the linux end, and framing mode encapsulation at the windows end.

Check the parameters in the windows driver properties. Windows 2000 defaults to "framing mode" translation. Change ray_cs to translate=1 to talk to Windows 2000.

The following commands should work. Note that "xxx" is not to be used literally, but represents the variable portion of a name, usually the version number. You need to be logged in as root to install pcmcia card services. There is much more detail and special case information in the PCMCIA-HOWTO included in the pcmcia-cs package.

Some users have had problems compiling due to not having all the required development packages installed. You must have at least the following packages installed.

• C compiler - one of:

  gcc

  egcs

  pgcc

• glibc-devel

• kernel-source

• make

There was a race condition in earlier versions of the driver between the first interrupt from the hardware and the device being opened. This is fixed in version 1.68. This error message happens occasionally in normal use if the kernel pushes packets at the card faster than they can be sent. However, if the card is unable to interrupt the PC, the transmit buffers will fill up, and never get emptied. Take a look at your IRQ's in /proc/interrupts. Perhaps selecting different IRQ's for card services in /etc/pcmcia/config.opts will enable them to get through.

This can be caused by a number of things. file (/var/log/messages for RedHat). Note that the following procedure is much easier to do after the machine has booted without the card, because all the messages in the logfile will be in a group. The burst of messages at bootup clutters the list and makes it hard to follow the sequence of events. Try setting pc_debug=3 in /etc/pcmcia/ray_cs.opts on both machines. Insert one card. Then, after the light comes on, insert the other. Look in the log file (/var/log/messages for RedHat). You should find:

ray_cs interrupt network your_essid started 
 on the first machine and 

ray_csinterrupt network your_essid joined 
 on the second machine.

If the first says started, and the second says joined, then the low level communication has been established. You should see some activity on the LED. The problem is at a "higher layer".

Translation/Encapsulation of ethernet and 802.11 frames. Some users have been unable to get ping to work unless they set translate=0. For users trying to communicate with windows machines, this setting is called "framing mode" in windows.

Wrong net parameters in /etc/pcmcia/network.opts. Note that WebGear's windows parameters must match the ray_cs.opts parameters to talk between windows and linux. The WebGear parameters are accessible in the advanced page of the driver properties page. Note that network_name and essid are not the same.

Wireless transmission of packets is inherently less reliable than ethernet. To make up for this, 802.11 cards retransmit a packet if an ack from the destination card is not received after a timeout. When you set up a bridge, the card is put into promiscuous mode so that it will receive all packets - even those destined for other hardware addresses. Because a bridge is "invisible" packets are sent to the address of the ethernet card on the other side of the bridge. Naturally, the card does not ack packets for other addresses, it would cause mayhem to do so. This results in the sending card retrying numerous times (most of which will be received and sent to the destination).

The only way to fix this is to implement at least a subset of access point (AP) capability in the driver. Infrastructure nets use an extra address in the 802.11 MAC header to allow for the final destination in addition to the immediate wireless destination address. Thus, acks work, and the packets can be transparently forwarded to their destination.