For general questions and bug reports about the orinoco driver, use the <orinoco-users@lists.sourceforge.net> list. You can subscribe at: https://lists.sourceforge.net/lists/listinfo/orinoco-users

For technical questions, feature request and development discussion, use the <orinoco-devel@lists.sourceforge.net> 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 <wireless@lists.samba.org 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 :-)

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/<version>/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".

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.

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.

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.

This is a persistent problem that 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 data into the card, ready for transmission. 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.

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).

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. As far as I can tell this is a different beast from the Prism chipset entirely, and definitely not supported by this driver.

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.
It seems that this is not necessary for the Intel PXA XScale.

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.

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 SA support even if your machine doesn't have/use conventional ISA slots). Recompile your kernel with CONFIG_ISA enabled.

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).

Don't use any of the 0.12 versions. A blunder on my part meant that we are attempting to use a locking model that's incompatible with the network layer.