> 	1. "FH" and "DS" cannot be set at all.  It just show the type of
> 	   PHY chip on the card, and printed at attaching the interface
> 	   would be enough.

I'm not sure I agree here; I'd prefer to see this information
available through the system call interface.  Also, Murphy's Law says
that if we change this, we'll discover N months later that someone's
built a dual-mode 802.11 card.

> 	2. Bit rate is not necessarily specified for most cases.
> 	   Both for infrastructure mode and ad-hoc (IBSS) mode,
> 	   spec says that the PHY with multirate support MUST use
> 	   basic rate for multicast/broadcast and control frames,
> 	   and MUST NOT transmit at a higher rate without prior knowledge
> 	   of destination's supported rate, which are shown by beacon
> 	   frames or association requests.

agreed.  it appears as if 802.11 can operate with multiple bit rates
simultaneously (a BSS -- the lower-level RF subnet concept in 802.11
-- has a *set* of supported rates which can all be in use, not a
single rate).  It may be desirable to have a knob to disable/enable
rates supported by a particular card (in the event that there are
interoperability problems at certain rates), but I don't have much
experience with multi-rate 802.11 networks..

> 	3. The infrastructure mode and the ad-hoc mode are clearly different
> 	   and cannot interoperable each other.  So they cannot be "media
> 	   options" but mutually exclusive "media types".

well, "full duplex" and "half duplex" for ethernet can't interoperate
either.  i'm not sure how this follows.

> And there are some more options to be defined for wireless LAN.
> 	create-ibss	Create its own IBSS and announce it when it fails
> 			to find or join existing IBSS.
> 			Only valid for the adhoc media type.
> 			Note that isolated two node with this option
> 			cannot talk to eath other even if they come closer
> 			again.

well, i don't have a copy of the wi hardware specs, but the awi
microcode supports a "background scan" mode which might be convinced
to let an IBSS leader scan for other IBSS's within range.

> 	no-bssid	Do not use bssid nor beacons at all.  It is just
> 			same as adhoc mode of WaveLAN (wi(4)).
> 			Only valid for the adhoc media type.

right, non-standard mode.


> 	wep		Enables WEP (Wired Equivalent Privacy).  It requires
> 			WEP encryption to communicate others.

yup. 

> 	power-mgmt	Enables power management capability.  Only available
> 			for infrastructure media type and it requires
> 			additional support by access points.

yup.  there may be some interop issues here as well.. I may need to
tweak various parameters on the basestation side, but turning on power
management on the wi* caused it to fail to interop with a baystack 660
DS basestation..

> Possibly more to be defined somewhere:
> 	desired ESSID	currently can be specified by the "nwid" parameter of
> 			ifconfig(8).  Empty string ('') means wildcard
> 			ESSID which allow to connect any access points.
> 	created ESSID	used for "create-ibss".  It may be the same string
> 			with desired ESSID but it should not be empty.

I'm not sure these two really need to be distinct.

> 	WEP key		used for "wep" encryption/decryption.

The protocol allows for up to four different WEP keys with different
key id's; there should also be a "key id to use on transmits".

> 	channel/pattern	used for "create-ibss" to determine the radio
> 			frequency (DS) or hopping pattern (FH) to be used
> 			to create IBSS.  Also used for "no-bssid".

right..

						- Bill