orinoco_cs: Orinoco and Prism 2 wireless card driver ---------------------------------------------------- A new driver for Lucent/Cabletron IEEE 802.11 wireless cards as well as most Prism II based wireless cards. This driver is designed as a replacement for the wvlan_cs.c driver - it's supposed to clean up some things in that driver, in particular its dependence on the rather ugly HCF-Light library from Lucent. This driver has been included in the Linux kernel since version 2.4.3. Usually it's easisest to use the driver in the kernel, only use the versions here if you need the latest experimental versions or if you need a later version but for some reason can't upgrade your kernel. Contact: David Gibson Frequently Asked Questions: ---------------------------------------------------------------------- Q: I have a question that's not answered here. Where do I ask it? For general questions and bug reports about the orinoco driver, use the list. You can subscribe at: https://lists.sourceforge.net/lists/listinfo/orinoco-users For technical questions, feature request and development discussion, use the list. You can subscribe at: https://lists.sourceforge.net/lists/listinfo/orinoco-devel For discussion of wireless networking issues which aren't orinoco driver specific (e.g. plans for community networks, which cards to purchase, where to get or how to design external antennae) try the list. You can subscribe at: http://lists.samba.org/listinfo/wireless *NB*: This list was originally intended for discussion of community wireless networks in Australia. It seems to have drifted to cover a wider area, but YMMV. I take no responsibility if you are flamed for being off-topic :-) ---------------------------------------------------------------------- Q: How do I compile/install the driver? The easiest way is to use the version included in the kernel source, or in David Hinds' pcmcia-cs package. If you need to install a newer version from ozlabs.org, you will need the kernel source for the kernel you are currently running. The Makefile included with the driver assumes that the link /lib/modules//build points to this, and that you are using the pcmcia modules from the kernel, rather than from pcmcia-cs. If that's true, then just unpack the driver tar file, run "make", become root and run "make install". ---------------------------------------------------------------------- Q: When I try to load the driver I get a message about "Card Services release does not match". What's wrong? This usually means that you've compiled the driver against the in-kernel pcmcia drivers, but you're using the pcmcia-cs drivers. To compile against the pcmcia-cs package drivers you need to change the PCMCIA_CS variable in the Makefile to point to your pcmcia-cs sources. ---------------------------------------------------------------------- Q: My machines with the orinoco driver in ad-hoc mode can't talk to machines running the wvlan_cs driver / FreeBSD's if_wi driver. What's up? There are actually two versions of ad-hoc mode which are not interoperable. One is the IEEE standard "IBSS" mode and the other is a Lucent proprietary protocol known as "demo ad-hoc mode". The orinoco driver defaults to using IBSS mode on firmware which supports it (>= 6.06 for Lucent cards), the wvlan_cs and FreeBSD driver default to demo ad-hoc mode. You'll have to switch one or the other end so they're using the same mode: For orinoco_cs/orinoco_plx/airport the command: iwpriv ethXX set_port3 1 will select demo ad-hoc mode, and: iwpriv ethXX set_port3 0 will select IBSS mode. For wvlan_cs the module parameters: port_type=1 allow_ibss=1 will select IBSS mode and port_type=3 will select demo ad-hoc mode. For FreeBSD the command wicontrol -p 1 && wicontrol -C 1 will select IBSS mode, and wicontrol -p 3 will select demo ad-hoc mode. ---------------------------------------------------------------------- Q: I get lots of "Error -110 writing Tx descriptor to BAP" or "Error -110 writing packet header to BAP" messages, whenever I try to do a big transfer. What's going on? This is a persistent problem we've had dealing with Intersil firmware, that we're having a lot of trouble pinning down and squashing. The error means that we're timing out while waiting for the firmware to respond to a request to write packet data into the card. It's not entirely clear why the firmware sometimes responds so slowly, in fact there now seems to be some evidence that there are multiple causes for this problem. (BAP stands for "Buffer Access Path" the mechanism for getting data in and out of the card's memory). At least one of the causes for this problem has been squashed in 0.13 and later versions (the card's two, supposedly independent, BAPs aren't quite). However there may be other more obscure cases in which it occurs. I'm very interested in reports of this behaviour on current versions, to try and find some patterns to the behaviour. In particular I'm interested to hear whether the problem occurs (in 0.13 or later) with WEP disabled. There is a report that setting a low RTS threshold (say 250 bytes) works around this problem (though it's certainly not an optimal solution). ---------------------------------------------------------------------- Q: Are the mini-PCI wireless cards used in Dell laptops (and some other brands) supported? Some of these are essentially a PCMCIA card with a PCI to PCMCIA bridge packaged into the mini-PCI form factor, so the PCMCIA subsystem should see it as a PCMCIA slot and be able to initialise the card. Some newer laptops have genuine PCI cards based on the Prism 2.5 chipset. These are supported by the orinoco_pci driver (note that this driver is not as well tested as the PCMCIA version). Some even newer Dell laptops have a PCI 802.11b card based on a Broadcom chip. This is entirely unrelated to the Prism2 chipset, and not supported by this driver. ---------------------------------------------------------------------- Q: Why do I get lots of "Error -16 writing packet header to BAP" messages in my log? This is an error reported by the firmware, but it is triggered by a major bug in all versions of the driver prior to 0.09a. Upgrade to the latest driver as soon as possible. ---------------------------------------------------------------------- Q: How do I get the driver to work on my ARM based machine? There seems to be a problem which causes one of the structures used in the driver to be misaligned on ARM machines (I believe this is a compiler bug on ARM). For now try compiling the driver with the option "-mstructure-size-boundary=8" - eventually the use of the structure in this manner is likely to be phased out removing the problem. This should no longer be necessary as of version 0.10. ---------------------------------------------------------------------- Q: I compiled the module from the sources on www.ozlabs.org, but when I try to load it, I get lots of "unresolved symbol" messages. Red Hat, Debian and most other distributions compile their kernels with "module symbol versioning" (CONFIG_MODVERSIONS) enabled. This causes some problems with compiling modules outside the kernel tree itself. You can either recompile the kernel with this option disabled, then recompile the module, or try adding: -DMODVERSIONS -include $(KERNEL_SRC)/include/linux/modversions.h to the CPPFLAGS option in the orinoco module Makefile. ---------------------------------------------------------------------- Q: The driver doesn't work and I get a message like "get dev info on socket 1 failed: Resource temporarily unavailable". This is an error from the PCMCIA subsystem for which there are several possible causes. 1) The single most common cause isn't a problem in the orinoco driver - the error is generated before the driver is even activated. It usually indicates a PCMCIA configuration problem. In particular it can be cause if you attempt to use the orinoco driver by putting: device "wvlan_cs" class "network" module "orinoco_cs" or similar in /etc/pcmcia/config. Instead you must individually bind each card to the "orinoco_cs" device. Usually, all you should need to do is leave the PCMCIA standard config files alone, and just drop hermes.conf from the driver package into /etc/pcmcia. 2) This problem can also be caused if your kernel lacks ISA support (16-bit PCMCIA is in some ways an extension of an ISA bus, so you need ISA support even if your machine doesn't have/use normal ISA slots). Recompile your kernel with CONFIG_ISA enabled. ---------------------------------------------------------------------- Q: When I try to compile the driver I get errors about "implicit declaration of min/max/min_t/max_t". The driver uses the new type safe min and max macros introduced in 2.4.10. You're using a copy of the kernel source from before this. Get some newer kernel source, or use the version of the driver included in David Hinds' pcmcia-cs package (which includes compatibility code). ---------------------------------------------------------------------- Q: I using version 0.12(something) and I'm getting lockups / it's not working. Don't use any of the 0.12 versions. A blunder on my part meant that we were attempting to use a locking model that's incompatible with the network layer.