Re: wireless: recap of current issues (configuration)

[Stuffed Crust <pizza@shaftnet.org>]

[-- Attachment #1: Type: text/plain, Size: 1748 bytes --]

On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote:
> One other thing: capability.  It's not enough to be able to configure
> the device, user-space tools also have to know what the device is
> capable of before they try touching it.  Ie, which ciphers, protocols,
> channels, etc.  Similar to the IWRANGE ioctl that there is now.  Half
> the problem now is that you can't reliably tell what drivers support
> which features, or how much they support a particular feature. 

This is an absolute requirement, especially when talking about 
encryption.  

You'd need, for example:

CAP_WEP_64
CAP_WEP_128
CAP_WEP_256 (non-standard, but often supported)
CAP_TKIP
CAP_MICHAELMIC
CAP_AES_CCMP

Then, to make things more complicated:

CAP_KEYMAPPING (can the hardware do keymapping?)
CAP_CAN_DISABLE_HWCRYPT (so if the hardware can't do TKIP, can we 
                         perform it on the host?)

And to make things even more complicated, I've seen hardware that 
supports disabling of hardware crypto, but not toggling it on the fly, 
thanks to never-fixed hardware bugs. (you have to perform a full 
reset/firmware load cycle.  this means you end up disabling host crypto 
altogether, at least if any of the networks you want to support include 
CCMP...

Other quirks -- hardware that requires host MICHAEL on transmits, but
handles it on reception, unless if the received frames are fragmented. 
Other hardware that does keymapping on rx frames, but for transmits
takes the raw keydata in the tx descriptor.  (but still requires host
MICHAEL)

The list goes on and on..

 - Solomon
-- 
Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 
Quidquid latine dictum sit, altum viditur.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]