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 <[email protected]>
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 <[email protected]> list. You can subscribe at:
https://lists.sourceforge.net/lists/listinfo/orinoco-users
For technical questions, feature request and development discussion,
use the <[email protected]> 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
<[email protected]> 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/<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".
----------------------------------------------------------------------
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.
|
