Static wep keys not set
proski at gnu.org
Fri Apr 6 22:04:56 EDT 2007
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.
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.
More information about the HostAP