Provided by: freebsd-manpages_7.1~beta1-1_all bug

NAME

     ray - Raytheon Raylink/Webgear Aviator PCCard driver

SYNOPSIS

     To compile this driver into the kernel, place the following line in your
     kernel configuration file:

           device ray

     Alternatively, to load the driver as a module at boot time, place the
     following line in loader.conf(5):

           if_ray_load="YES"

DESCRIPTION

     The ray driver provides support for Raytheon Raylink adapters (commonly
     available as Webgear Aviator, Webgear Aviator Pro and Raylink PC Card
     devices.)  The core of the Raylink cards is a frequency hopping PHY with
     an IEEE 802.11 style MAC that interacts with the host using shared memory
     and mailboxes.

     The ray driver currently supports ad-hoc operation mode and the Aviator
     cards.  Infrastructure mode, interworking with Windows 2000/Linux/NetBSD,
     Raylink PC Cards and Aviator Pros is rudimentary and in active
     development.  The ray driver currently encapsulates all IP and ARP
     traffic as Ethernet 2 frames within an IEEE 802.11 frame.  Other
     translations will be forthcoming as needed.  Transmit speed is selectable
     between 0.5Mbps, 1Mbp , 1.5Mbps or 2Mbps all with auto fallback.

     By default, the ray driver configures the card for ad-hoc operation.  In
     this mode, stations can communicate amongst each other without the aid of
     an access point.  To join a managed service set, the driver must be set
     for infrastructure mode using the raycontrol(8) utility.

     There are two known firmware versions; version 4 and version 5.  Version
     4 firmware was shipped on the orignal Webgear Aviators Version 5 firmware
     is used as part of the Windows 2000 upgrade from Webgear and on the
     Aviator Pro, and Raylink PC Cards cards.  Version 4 is not likely to be
     100% IEEE 802.11 compliant - version 5 should be.

     For more information on configuring this device, see ifconfig(8) and
     raycontrol(8).

DIAGNOSTICS

     The following messages occur when there are problems setting up the
     memory mapped buffers due to nits in pccardd(8).

     ray?: pccardd did not map CM - giving up  See the BUGS section and
     contact the author for help enclosing a copy of the output from dmesg(8).
     This message only occurs on 3.x systems.

     ray?: fixing up CM ...
     ray?: fixing up AM ...  The driver is fixing up PCCard memory management
     after mis-configuration by pccardd(8), benign.

     On 4.x and -current systems the following messages can occur when the
     memory mapped buffers are set up.

     ray?: allocated common memory:
     .  start 0xd0000 count 0xc0000 flags 0x40  Benign.

     ray?: allocated attribute memory:
     .  start 0xdc000 count 0x1000 flags 0x50  Benign.

     ray?: allocated irq:
     .  start 0x9 count 0x1  Benign.

     ray?: Cannot allocate attribute memory
     ray?: Cannot allocate common memory
     ray?: Cannot allocate irq
     ray?: Failed to setup irq
     ray?: CARD_SET_MEMORY_OFFSET returned 0x??
     ray?: CARD_SET_RES_FLAGS returned 0x??  See the BUGS section and contact
     the author for help enclosing a copy of the output from dmesg(8) in your
     email.

     If the kernel is booted with the verbose flag turned on then the extra
     information is printed when the driver is probed.  These messages are
     also seen when the RAY_DBG_BOOTPARAM bit in the RAY_DEBUG option is
     turned on, as is the case for all existing versions of the driver.

     ray?: memory start 0x???? count 0x???? flags 0x???? offset 0x????
     Description of memory map settings on entry to the driver.

     ray?: irq start 0x???? count 0x????  Description of irq settings on entry
     to the driver (only on 4.1 and above).

     On start-up the driver will report hardware failures thus:

     ray?: card failed self test: status 0x??<???>  The card failed to come
     ready after it was plugged in to the PCCard slot.  The most common cause
     of this message is incorrect PCCard memory management (indicated by a
     status of 0xff or 0x55).  Bent cards might say that the receiver
     calibration failed.  If you are brave enough removing the base of the
     case can resurrect cards (no warranties etc.).

     ray?: unsupported firmware version 0x??  Self explanatory.  Contact the
     author for help enclosing a copy of the output from dmesg(8).

     The following messages are enabled using the debug option of ifconfig(8).

     ray?: cannot transmit - not running  A packet was ready for transmission
     but the NIC is not connected to a BSS.  May occur when removing the
     PCCard.

     ray?: cannot transmit - no network  The wireless NIC has roamed from an
     access point and not connected with a new one yet.

     ray?: cannot transmit - ECF busy  The controller firmware was busy when a
     packet was about to be sent out.  It will be retried automatically.

     ray?: mbuf too long ??  Should never happen, and if it does represents
     something wrong in the generic Ethernet driver in the kernel.

     ray?: could not pullup ether  Problem with re-aligning mbufs.  Very
     unlikely to happen.

     ray?: unknown framing type ??  An impossible error - mail the author.

     ray?: could not translate packet  An error occurred when trying to re-
     frame a packet for transmission.

     ray?: ECF busy, dropping packet  The NIC was busy just before a packet
     was to be transmitted.

     ray?: tx completed but status is fail  Typically associated with
     transmissions to out of range NICs.

     ray?: packet too big or too small  A received packet was impossibly small
     or too large to fit into an mbuf.

     ray?: MGETHDR failed  The driver could not get a mbuf to store a received
     packet into.  Try increasing MAXUSERS in your kernel configuration.

     ray?: MCLGET failed  The driver could not get a mbuf to store a received
     packet into.  Try increasing MAXUSERS in your kernel configuration.

     ray?: bad length current 0x?? pktlen 0x??  The lengths of a fragmented
     packet were inconsistent.

     ray?: bad rcs index 0x??  The index of the buffer used for part of a
     fragmented packet is outside of the usable range.

     ray?: header not version 0 fc0 0x??  The received IEEE 802.11 packet had
     an unknown header type.  Represents link corruption or non standard nodes
     in the network.

     ray?: unknown packet fc0 0x??  The received IEEE 802.11 packet type is
     unknown.  Represents link corruption or non standard nodes in the
     network.

     ray?: reserved DATA packet subtype 0x??  The received IEEE 802.11 data
     packet has a reserved (i.e., not allowed) subtype.  Represents link
     corruption or non standard nodes in the network.

     ray?: MGT TODS/FROMDS wrong fc1 0x??  The received IEEE 802.11 management
     packet had a malformed header.  Represents link corruption or non
     standard nodes in the network.

     ray?: unexpected MGT packet subtype 0x??  The received IEEE 802.11
     management packet was of a subtype that the NIC should have processed.
     Benign, but might represent buggy firmware.

     ray?: reserved MGT packet subtype 0x??  The received IEEE 802.11
     management packet has a reserved (i.e., not allowed) subtype.  Represents
     link corruption or non standard nodes in the network.

     ray?: open system authentication request  Self explanatory and for
     testing Aviator Pro interworking.

     ray?: authentication failed with status ??  Self explanatory and
     currently represents a bug as the driver never requests authentication.

     ray?: shared key authentication request  Self explanatory and for testing
     Aviator Pro interworking.

     ray?: reserved authentication subtype 0x??  An authentication request has
     been received for a reserved (i.e., not allowed) subtype.  Represents
     link corruption or non standard nodes in the network.

     ray?: CTL TODS/FROMDS wrong fc1 0x??  The received IEEE 802.11 management
     packet had a malformed header.  Represents link corruption or non
     standard nodes in the network.

     ray?: unexpected CTL packet subtype 0x??  The received IEEE 802.11
     control packet was of a subtype that the NIC should have processed.
     Benign, but might represent buggy firmware.

     ray?: reserved CTL packet subtype 0x??  The received IEEE 802.11 control
     packet has a reserved (i.e., not allowed) subtype.  Represents link
     corruption or non standard nodes in the network.

     ray?: bad ccs index 0x??  The NIC has generated an interrupt with an
     incorrect control block.

     ray?: unexpected UPDATE_APM
     ray?: unexpected TEST_MEM
     ray?: unexpected SHUTDOWN
     ray?: unexpected DUMP_MEM
     ray?: unexpected START_TIMER  The NIC has generated an interrupt
     signalling that the indicated command has completed.  At present these
     commands are never issued by the driver, so they represent
     firmware/hardware/driver bugs.

     ray?: unknown command 0x??  The NIC has generated an interrupt for an
     unknown command completion.  Represents firmware/hardware/driver bugs.

     ray?: unexpected JAPAN_CALL_SIGNAL  The NIC has generated an interrupt
     with a control block requesting processing of a packet that is only ever
     used in Japanese RCR certification tests.  Represents
     firmware/hardware/driver bugs unless you are trying to certify the NICs
     in Japan (in which case you would have to of modified the driver and this
     manual is out of date).

     ray?: spinning  The controller firmware was busy when a command was about
     to be issued.  If the driver spins for too long then it will panic.  See
     the BUGS section for details.

     ray?: freeing free ccs 0x??  Benign warning that may occur when the NIC
     is ejected.

SEE ALSO

     arp(4), netintro(4), ifconfig(8), pccardd(8), raycontrol(8)

HISTORY

     The ray device driver first appeared in FreeBSD 3.3.

AUTHORS

     Early versions of this ray driver were a port of the NetBSD driver by
     Christian E. Hopps.  The driver was re-structured by Duncan Barclay
     〈dmlb@FreeBSD.org〉, so that dhclient(8) would work.

BUGS

     Infra-structure mode is not supported yet.  The driver is likely to panic
     if it is set into this mode.  Testers are encouraged to contact the
     author.

     Currently FreeBSD has a small problem managing and setting up the correct
     memory maps.  However, this driver should reset the memory maps correctly
     - it works around pccardd(8) (where it reads the CIS for common memory,
     sets it all up and then throws it all away assuming the card is an ed(4)
     driver...).  Note that this could be dangerous (because it does not
     interact with pccardd(8)) if you use other memory mapped cards at the
     same time or have SCSI cards with on-board BIOS.

     More encapsulations and translations could be supported, but they have
     little value unless someone can demonstrate that the ray cards will
     communicate with other manufacturers cards.  Version 4 and firmware is
     not IEEE 802.11 compliant, but version 5 is.

     To communicate with Windows machines ensure that the Windows machine
     creates the BSS/IBSS.

     The driver currently panics on some errors that it should recover from.
     These will be removed RSN.