Static wep keys not set

[Nicolas DICHTEL]

Le 07.04.2007 04:04, Pavel Roskin a ?crit :
> On Thu, 2007-04-05 at 10:01 +0200, Nicolas Dichtel wrote:
>> Pavel Roskin a ?crit :
>>> On Tue, 2007-04-03 at 18:10 +0200, Nicolas Dichtel wrote:
>>>> I've already sent a mail (and a proposal patch) about this issue
>>>> (http://lists.shmoo.com/pipermail/hostap/2006-November/014640.html).
>>>>
>>>> As I said in my previous mail:
>>>>
>>>> 802.11 specifications say:
>>>> "APs set the Privacy sub?eld to 1 within transmitted Beacon, Probe 
>>>> Response, Association Response, and
>>>> Reassociation Response management frames if WEP encryption is required 
>>>> for all data type frames
>>>> exchanged within the BSS. If WEP encryption is not required, the Privacy 
>>>> sub?eld is set to 0."
>>> It sounds like if the privacy bit is set before the key, all
>>> communication will stop to satisfy that requirement.  Setting the key
>>> first seems more reasonable to me.  Is my understanding correct?
>> If we set the key before the privacy bit, this requirement will not be 
>> satisfy too ;-)
>
> I didn't hear from you, so I don't know what you meant.  I'm assuming
> you don't know what you are talking about.
Sorry, I was busy ...
>
> My reading of section 8.3.2 of the 802.11 standard is that setting the
> transmit WEP key and the privacy bit can be done in any order.  It the
> privacy bit is set, but no key material is available, the driver is
> supposed to report individual packets as undeliverable.  Refusing to set
> the privacy bit is not a standard behavior.
I agree.
>
> Therefore, madwifi must be wrong here, and not hostapd.  In my opinion,
> the patch for hostapd should be rejected.
Which patch exactly ? My patch allow just to set privacy bit if hostapd
is configuring with static WEP key.

Nicolas