Static wep keys not set
Tue Apr 10 01:20:41 PDT 2007
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
>>>> 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.
> 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.
More information about the Hostap