Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
RAY(4)		     FreeBSD/i386 Kernel Interfaces Manual		RAY(4)

NAME
     ray -- Raytheon Raylink/Webgear Aviator PCCard driver

SYNOPSIS
     device ray

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 develop-
     ment.  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 mem-
     ory mapped	buffers	due to nits in pccardd(8).

     ray?: pccardd did not map CM - giving up  See the BUGS section and	con-
     tact 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 calibra-
     tion 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	occured	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 trans-
     missions 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	unkown 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 net-
     work.

     ray?: reserved DATA packet	subtype	0x??  The received IEEE	802.11 data
     packet has	a reserved (i.e. not allowed) subtype.	Represents link	cor-
     ruption 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 stan-
     dard nodes	in the network.

     ray?: unexpected MGT packet subtype 0x??  The received IEEE 802.11	man-
     agement 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 manage-
     ment 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	test-
     ing Aviator Pro interworking.

     ray?: authentication failed with status ??	 Self explanatory and cur-
     rently 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 stan-
     dard nodes	in the network.

     ray?: unexpected CTL packet subtype 0x??  The received IEEE 802.11	con-
     trol 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	cor-
     ruption 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 sig-
     nalling that the indicated	command	has completed.	At present these com-
     mands are never issued by the driver, so they represent firmware/hard-
     ware/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/hard-
     ware/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	doesn't	inter-
     act 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 com-
     municate 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 cre-
     ates the BSS/IBSS.

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

FreeBSD	9.2			March 21, 2000			   FreeBSD 9.2

NAME | SYNOPSIS | DESCRIPTION | DIAGNOSTICS | SEE ALSO | HISTORY | AUTHORS | BUGS

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=ray&sektion=4&manpath=FreeBSD+4.5-RELEASE>

home | help