I'm sorry there is very slow progress in this subject...

First, I don't want to configure all possible parameters defined in 802.11
specification through ifconfig.  There are so many parameters defined as
well as MIB definitions.  We just should refer the MIBs for this purpose.

On the other hand, most (all?) of 802.11 firmware only support small
subset of the spec as well as a few local extensions.  We should define
most common part which are desired to be configured via ifconfig, IMO.
I understand some un-configurable parameters are also useful to display,
e.g. current ESSID, current channel, etc.

Well, since it seems that the experience is still not enough to determine
which parameters are important and considered as common, I'll implement
separate awictl command for awi(4) driver and postpone changing ifconfig
for now.

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

Though I don't want to all parameters to be configurable through ifconfig,
as I said above, I agree it is categorized to useful information to show
(i.e. read only).

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

And some cards may not support such functionality which limits the transfer
rate or fixes to higher rate.  Also it is unclear whether fixed receiving
rate makes sense or not.

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

Hmm.  Actually, I don't have a strong opinion about the differences between
'media' and 'mediaopt'.  What is the 'media'?

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

It may be true, though it won't be common to all wireless cards.

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

Right.

Atsushi