Static wep keys not set
proski at gnu.org
Thu Apr 5 11:31:10 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'm afraid your joke is above my head.
I believe setting the transmission WEP key would not prevent sending
encrypted frames and receiving encrypted and unencrypted frames, even if
the privacy bit is not set.
Of course, hostapd shouldn't care if the communication is possible
during the transition. In fact, it should card about security above
On the other hand, the driver doesn't know that setting the privacy bit
is temporary. The driver is asked to do encryption without any key
material. I think it's legitimate for a driver to refuse it.
More information about the HostAP