[RFC] mac80211: fix software decryption

[RFC] mac80211: fix software decryption

[Johannes Berg]

When doing key selection for software decryption, mac80211 gets
a few things wrong: it always uses pairwise keys if configured,
even if the frame is addressed to a multicast address. Also, it
doesn't allow using a key index of zero if a pairwise key has
also been found.

This patch changes the key selection code to be (more) in line
with the 802.11 specification. I have confirmed that with this,
multicast frames are correctly decrypted and I've tested with
WEP as well.

While at it, I've cleaned up the semantics of the hardware flags
IEEE80211_HW_WEP_INCLUDE_IV and IEEE80211_HW_DEVICE_HIDES_WEP
and clarified them in the mac80211.h header; it is also now
allowed to set the IEEE80211_HW_DEVICE_HIDES_WEP option even if
it only applies to frames that have been decrypted by the hw,
unencrypted frames must be dropped but encrypted frames that
the hardware couldn't handle can be passed up unmodified.

Support for group keys in IBSS mode is pending until we figure
out how to handle that. It will also, like with VLANs, require
a hardware encryption API change.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>

---
Michael, you should really get rid of IEEE80211_HW_DEVICE_HIDES_WEP
in b43, otherwise you'll have to start dropping unencrypted
frames and handle 802.1X callbacks and stuff to guarantee
proper operation.

I would be much in favour of removing the option completely,
it's IMHO misused in b43 and no other driver uses it.

Volker, can you test whether this patch (possibly together with
yours removing privacy and key index checking) helps with your
dynamic WEP? I think it should.

Larry, could you verify that this gets rid of your messages? It
does for me but then I'm using CCMP and not TKIP so maybe there's
something special again.

This patch applies on top of all my other patches, as usual
available at http://johannes.sipsolutions.net/patches/kernel/all/.

 include/net/mac80211.h |   37 +++++++++++---
 net/mac80211/rx.c      |  125 ++++++++++++++++++++++++++++++-------------------
 net/mac80211/wpa.c     |    7 +-
 3 files changed, 112 insertions(+), 57 deletions(-)

--- wireless-dev.orig/net/mac80211/rx.c	2007-08-17 03:10:13.323466559 +0200
+++ wireless-dev/net/mac80211/rx.c	2007-08-17 03:10:58.983466559 +0200
@@ -335,52 +335,83 @@ static ieee80211_txrx_result
 ieee80211_rx_h_load_key(struct ieee80211_txrx_data *rx)
 {
 	struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) rx->skb->data;
-	int always_sta_key;
+	int keyidx;
+	int hdrlen;
+	int trying_wep = 0;
+
+	/*
+	 * Key selection 101
+	 *
+	 * There are three types of keys:
+	 *  - GTK (group keys)
+	 *  - PTK (pairwise keys)
+	 *  - STK (station-to-station pairwise keys)
+	 *
+	 * When selecting a key, we have to distinguish between multicast
+	 * (including broadcast) and unicast frames, the latter can only
+	 * use PTKs and STKs while the former always use GTKs. Unless, of
+	 * course, actual WEP keys ("pre-RSNA") are used, then unicast
+	 * frames can also use key indizes like GTKs. Hence, if we don't
+	 * have a PTK/STK we check the key index for a WEP key.
+	 *
+	 * There is also a slight problem in IBSS mode: GTKs are negotiated
+	 * with each station, that is something we don't currently handle.
+	 */
 
-	if (rx->sdata->type == IEEE80211_IF_TYPE_STA)
-		always_sta_key = 0;
-	else
-		always_sta_key = 1;
+	if (!(rx->fc & IEEE80211_FCTL_PROTECTED))
+		return TXRX_CONTINUE;
 
-	if (rx->sta && rx->sta->key && always_sta_key) {
-		rx->key = rx->sta->key;
+	/*
+	 * No point in finding a key if the frame is neither
+	 * addressed to us nor a multicast frame.
+	 */
+	if (!rx->u.rx.ra_match)
+		return TXRX_DROP;
+
+	if (is_multicast_ether_addr(hdr->addr1) || !rx->sta) {
+ find_by_index:
+		/*
+		 * The device doesn't give us the IV so won't be
+		 * able to look up the key. That's ok though, we
+		 * don't need to decrypt the frame, we just won't
+		 * be able to keep statistics accurate.
+		 * Except for key threshold notifications, should
+		 * we somehow allow the driver to tell us which key
+		 * the hardware used if this flag is set?
+		 */
+		if (!(rx->local->hw.flags & IEEE80211_HW_WEP_INCLUDE_IV))
+			return TXRX_CONTINUE;
+
+		hdrlen = ieee80211_get_hdrlen(rx->fc);
+
+		if (rx->skb->len < 8 + hdrlen)
+			/* COUNT THIS? */
+			return TXRX_DROP;
+		/*
+		 * no need to call ieee80211_wep_get_keyidx,
+		 * it verifies a bunch of things we've done already
+		 */
+		keyidx = rx->skb->data[hdrlen + 3] >> 6;
+
+		/*
+		 * TODO: handle IBSS! We can have per-STA group keys there!
+		 */
+		rx->key = rx->sdata->keys[keyidx];
+
+		/*
+		 * If we got here for WEP, make sure we got WEP
+		 */
+		if (trying_wep && rx->key && rx->key->conf.alg != ALG_WEP)
+			rx->key = NULL;
 	} else {
-		if (rx->sta && rx->sta->key)
-			rx->key = rx->sta->key;
-		else
-			rx->key = rx->sdata->default_key;
-
-		if ((rx->local->hw.flags & IEEE80211_HW_WEP_INCLUDE_IV) &&
-		    rx->fc & IEEE80211_FCTL_PROTECTED) {
-			int keyidx = ieee80211_wep_get_keyidx(rx->skb);
-
-			if (keyidx >= 0 && keyidx < NUM_DEFAULT_KEYS &&
-			    (!rx->sta || !rx->sta->key || keyidx > 0))
-				rx->key = rx->sdata->keys[keyidx];
-
-			if (!rx->key) {
-				if (!rx->u.rx.ra_match)
-					return TXRX_DROP;
-				if (net_ratelimit())
-					printk(KERN_DEBUG "%s: RX WEP frame "
-					       "with unknown keyidx %d "
-					       "(A1=" MAC_FMT
-					       " A2=" MAC_FMT
-					       " A3=" MAC_FMT ")\n",
-					       rx->dev->name, keyidx,
-					       MAC_ARG(hdr->addr1),
-					       MAC_ARG(hdr->addr2),
-					       MAC_ARG(hdr->addr3));
-				/*
-				 * TODO: notify userspace about this
-				 * via cfg/nl80211
-				 */
-				return TXRX_DROP;
-			}
+		rx->key = rx->sta->key;
+		if (!rx->key) {
+			trying_wep = 1;
+			goto find_by_index;
 		}
 	}
 
-	if (rx->fc & IEEE80211_FCTL_PROTECTED && rx->key && rx->u.rx.ra_match) {
+	if (rx->key && rx->u.rx.ra_match) {
 		rx->key->tx_rx_count++;
 		if (unlikely(rx->local->key_tx_rx_threshold &&
 			     rx->key->tx_rx_count >
@@ -535,10 +566,6 @@ ieee80211_rx_h_wep_weak_iv_detection(str
 static ieee80211_txrx_result
 ieee80211_rx_h_wep_decrypt(struct ieee80211_txrx_data *rx)
 {
-	/* If the device handles decryption totally, skip this test */
-	if (rx->local->hw.flags & IEEE80211_HW_DEVICE_HIDES_WEP)
-		return TXRX_CONTINUE;
-
 	if ((rx->key && rx->key->conf.alg != ALG_WEP) ||
 	    !(rx->fc & IEEE80211_FCTL_PROTECTED) ||
 	    ((rx->fc & IEEE80211_FCTL_FTYPE) != IEEE80211_FTYPE_DATA &&
@@ -890,8 +917,14 @@ ieee80211_rx_h_802_1x_pae(struct ieee802
 static ieee80211_txrx_result
 ieee80211_rx_h_drop_unencrypted(struct ieee80211_txrx_data *rx)
 {
-	/*  If the device handles decryption totally, skip this test */
-	if (rx->local->hw.flags & IEEE80211_HW_DEVICE_HIDES_WEP)
+	/*
+	 * Pass through unencrypted frames if the hardware might have
+	 * decrypted them already without telling us, but that can only
+	 * be true if we either didn't find a key or the found key is
+	 * uploaded to the hardware.
+	 */
+	if ((rx->local->hw.flags & IEEE80211_HW_DEVICE_HIDES_WEP) &&
+	    (!rx->key || rx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE))
 		return TXRX_CONTINUE;
 
 	/* Drop unencrypted frames if key is set. */
--- wireless-dev.orig/include/net/mac80211.h	2007-08-17 03:10:11.453466559 +0200
+++ wireless-dev/include/net/mac80211.h	2007-08-17 03:10:13.393466559 +0200
@@ -1,7 +1,9 @@
 /*
- * Low-level hardware driver -- IEEE 802.11 driver (80211.o) interface
+ * mac80211 <-> driver interface
+ *
  * Copyright 2002-2005, Devicescape Software, Inc.
  * Copyright 2006-2007	Jiri Benc <jbenc@suse.cz>
+ * Copyright 2007	Johannes Berg <johannes@sipsolutions.net>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -454,10 +456,16 @@ struct ieee80211_hw {
 	 */
 #define IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE (1<<1)
 
-	/* Some devices handle decryption internally and do not
+	/*
+	 * Some devices handle decryption internally and do not
 	 * indicate whether the frame was encrypted (unencrypted frames
 	 * will be dropped by the hardware, unless specifically allowed
-	 * through) */
+	 * through.)
+	 * It is permissible to not handle all encrypted frames and fall
+	 * back to software encryption; however, if this flag is set
+	 * unencrypted frames must be dropped unless the driver is told
+	 * otherwise via the set_ieee8021x() callback.
+	 */
 #define IEEE80211_HW_DEVICE_HIDES_WEP (1<<2)
 
 	/* Whether RX frames passed to ieee80211_rx() include FCS in the end */
@@ -471,16 +479,29 @@ struct ieee80211_hw {
 	 * can fetch them with ieee80211_get_buffered_bc(). */
 #define IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING (1<<4)
 
+	/*
+	 * This flag is only relevant if hardware encryption is used.
+	 * If set, it has two meanings:
+	 *  1) the IV and ICV are present in received frames that have
+	 *     been decrypted (unless IEEE80211_HW_DEVICE_HIDES_WEP is
+	 *     also set)
+	 *  2) on transmission, the IV should be generated in software.
+	 *
+	 * Please let us know if you *don't* use this flag, the stack would
+	 * really like to be able to get the IV to keep key statistics
+	 * accurate.
+	 */
 #define IEEE80211_HW_WEP_INCLUDE_IV (1<<5)
 
 	/* Force software encryption for TKIP packets if WMM is enabled. */
 #define IEEE80211_HW_NO_TKIP_WMM_HWACCEL (1<<7)
 
-	/* Some devices handle Michael MIC internally and do not include MIC in
-	 * the received packets passed up. device_strips_mic must be set
-	 * for such devices. The 'encryption' frame control bit is expected to
-	 * be still set in the IEEE 802.11 header with this option unlike with
-	 * the device_hides_wep configuration option.
+	/*
+	 * Some devices handle Michael MIC internally and do not include MIC in
+	 * the received packets passed up. This flag must be set for such
+	 * devices. The 'encryption' frame control bit is expected to be still
+	 * set in the IEEE 802.11 header with this option unlike with the
+	 * IEEE80211_HW_DEVICE_HIDES_WEP flag.
 	 */
 #define IEEE80211_HW_DEVICE_STRIPS_MIC (1<<8)
 
--- wireless-dev.orig/net/mac80211/wpa.c	2007-08-17 03:10:07.633466559 +0200
+++ wireless-dev/net/mac80211/wpa.c	2007-08-17 03:10:13.403466559 +0200
@@ -167,9 +167,10 @@ ieee80211_rx_h_michael_mic_verify(struct
 
 	fc = rx->fc;
 
-	/* If device handles decryption totally, skip this check */
-	if ((rx->local->hw.flags & IEEE80211_HW_DEVICE_HIDES_WEP) ||
-	    (rx->local->hw.flags & IEEE80211_HW_DEVICE_STRIPS_MIC))
+	/*
+	 * No way to verify the MIC if the hardware stripped it
+	 */
+	if (rx->local->hw.flags & IEEE80211_HW_DEVICE_STRIPS_MIC)
 		return TXRX_CONTINUE;
 
 	if (!rx->key || rx->key->conf.alg != ALG_TKIP ||

Re: [RFC] mac80211: fix software decryption with b43legacy

[Larry Finger]

I have added the lists to this message.

I got b43legacy up and running with the software decryption modifications. It started OK with 
WPA-PSK TKIP encryption, but soon thereafter, I got this message:

eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out of range

I don't know why this happened. I didn't move away from the AP, or do anything that should have 
caused loss of a probe response; however, immediately after that, I got this GPF:

general protection fault: 0000 [1] SMP
CPU 0
Modules linked in: nfs af_packet snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device vboxdrv
cpufreq_conservative cpufreq_ondemand cpufreq_userspace cpufreq_powersave powernow_k8 freq_table
thermal processor button battery ac nls_utf8 ntfs loop dm_mod nfsd exportfs lockd nfs_acl
auth_rpcgss sunrpc snd_hda_intel rc80211_simple snd_pcm snd_timer ohci_hcd snd ohci1394 ehci_hcd
ieee1394 soundcore b43legacy sdhci usbcore mmc_core mac80211 cfg80211 ide_cd cdrom forcedeth
snd_page_alloc i2c_nforce2 ssb ext3 mbcache jbd sg edd fan sata_nv libata amd74xx sd_mod scsi_mod
ide_disk ide_core
Pid: 2087, comm: b43legacy Not tainted 2.6.23-rc3-Ldev-gf5a42059-dirty #13
RIP: 0010:[<ffffffff803fe191>]  [<ffffffff803fe191>] __mutex_unlock_slowpath+0x6b/0x13a
RSP: 0018:ffff810056bd9b30  EFLAGS: 00010016
RAX: 0000000000007b64 RBX: ffff81005825e978 RCX: 0000000000000003
RDX: ffff810037f3d080 RSI: 0000000000000008 RDI: 6b6b6b6b6b6b6ba3
RBP: ffff810056bd9b50 R08: 0000000000000000 R09: ffff81005825e978
R10: ffff810056bd9b80 R11: ffff810037f3d080 R12: 6b6b6b6b6b6b6ba3
R13: 0000000000000246 R14: 6b6b6b6b6b6b6bab R15: ffff8100580564c0
FS:  00002b4afda060b0(0000) GS:ffffffff80539000(0000) knlGS:00000000f479eb90
CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 00000000f4e88bd0 CR3: 0000000057aa2000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process b43legacy (pid: 2087, threadinfo ffff810056bd8000, task ffff810037f3d080)
Stack:  ffff81005825e978 ffff81005825c2f0 ffff8100580564c0 ffff81005825c2f0
  ffff810056bd9b60 ffffffff803fe269 ffff810056bd9b80 ffffffff8814d704
  ffff81005825c2f0 ffff810058056640 ffff810056bd9bb0 ffffffff8813cd4f
Call Trace:
  [<ffffffff803fe269>] mutex_unlock+0x9/0xb
  [<ffffffff8814d704>] :mac80211:ieee80211_key_free+0x33/0x37
  [<ffffffff8813cd4f>] :mac80211:sta_info_free+0x92/0xae
  [<ffffffff881427dc>] :mac80211:ieee80211_associated+0x100/0x1ec
  [<ffffffff88143646>] :mac80211:ieee80211_sta_work+0x0/0x182e

The rest of the call trace is available if needed. The crash occurred when ieee80211_key_free was
trying to unlock the mutex key_idx. I added printk's to dump the pointer to sdata at the point where 
that mutex is initialized and where the key is freed. The mutex that errs was inited.

Note: For this run, I did not have a set_key callback routine defined. I also tried it with a 
callback routine that immediately returns -ENOSPC. It didn't make any difference.

Please let me know what further debug info you need.

Larry

Re: [RFC] mac80211: fix software decryption with b43legacy

[Johannes Berg]

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

On Sat, 2007-08-18 at 15:13 -0500, Larry Finger wrote:

> eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out of range

odd.

> I don't know why this happened. I didn't move away from the AP, or do anything that should have 
> caused loss of a probe response; however, immediately after that, I got this GPF:

I'll look into it, thanks.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]

Re: [RFC] mac80211: fix software decryption with b43legacy

[Johannes Berg]

On Sat, 2007-08-18 at 15:13 -0500, Larry Finger wrote:

> The rest of the call trace is available if needed. The crash occurred when ieee80211_key_free was
> trying to unlock the mutex key_idx. I added printk's to dump the pointer to sdata at the point where 
> that mutex is initialized and where the key is freed. The mutex that errs was inited.

Ho humm, yes, I'm dumb, patch below but I'll fold it into my key patch.
Sorry about that, classic use-after-free condition here.

johannes

--- wireless-dev.orig/net/mac80211/key.c	2007-08-20 14:07:43.165963896 +0200
+++ wireless-dev/net/mac80211/key.c	2007-08-20 14:08:04.265963896 +0200
@@ -255,12 +255,16 @@ static void __ieee80211_key_free(struct 
 
 void ieee80211_key_free(struct ieee80211_key *key)
 {
+	struct ieee80211_sub_if_data *sdata;
+
 	if (!key)
 		return;
 
-	mutex_lock(&key->sdata->key_mtx);
+	sdata = key->sdata;
+
+	mutex_lock(&sdata->key_mtx);
 	__ieee80211_key_free(key);
-	mutex_unlock(&key->sdata->key_mtx);
+	mutex_unlock(&sdata->key_mtx);
 }
 
 void ieee80211_set_default_key(struct ieee80211_sub_if_data *sdata, int idx)

Re: [RFC] mac80211: fix software decryption with b43legacy

[Larry Finger]

Johannes Berg wrote:
> On Sat, 2007-08-18 at 15:13 -0500, Larry Finger wrote:
> 
>> The rest of the call trace is available if needed. The crash occurred when ieee80211_key_free was
>> trying to unlock the mutex key_idx. I added printk's to dump the pointer to sdata at the point where 
>> that mutex is initialized and where the key is freed. The mutex that errs was inited.
> 
> Ho humm, yes, I'm dumb, patch below but I'll fold it into my key patch.
> Sorry about that, classic use-after-free condition here.

The patch fixed the crash. The reason for the "lost AP" is that WPA isn't working for b43legacy, 
with or without your patches. It used to work and I have no idea why it fails now.

Thanks,

Larry

Re: [RFC] mac80211: fix software decryption with b43legacy

[Ulrich Kunitz]

Larry Finger wrote:

> I have added the lists to this message.
> 
> I got b43legacy up and running with the software decryption modifications. 
> It started OK with WPA-PSK TKIP encryption, but soon thereafter, I got this 
> message:
> 
> eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out of range
> 

Since the git tree reorg wireless-dev branch created comparable
problems for zd1211rw-mac80211 too. It might be related:

Aug 19 07:08:51 keks kernel: [   83.572628] wlan0: CCMP replay detected for RX frame from 00:04:0e:68:ad:70 (RX PN 00000000000c <= prev. PN 00000000000c)
Aug 19 07:08:54 keks kernel: [   87.432010] usb 1-2: handle_regs_int() regs interrupt ignored
Aug 19 07:08:55 keks kernel: [   87.898447] wlan0: No ProbeResp from current AP 00:04:0e:68:ad:70 - assume out of range
Aug 19 07:08:55 keks kernel: [   87.899649] wmaster0: Removed STA 00:04:0e:68:ad:70
Aug 19 07:08:55 keks kernel: [   87.901406] wlan0: set_encrypt - unknown addr 00:04:0e:68:ad:70

The first message might be a simple duplicate. The
handle_regs_int() is absolutely suspicious and I cannot really
explain it right now. The "No ProbeResp" might be a follow-up
problem. The whole USB subsystem becomes absolutely instable to
the point that I can't use keyboard and mouse anymore. 

I will try Johannes' patch tomorrow.

BTW the wireless-dev reorg makes it impossible to actually use
git-bisect to find the patch, which caused the problem. 

BTW the current Linus tree following patch doesn't work with the
current zd1211rw-mac80211. The offending patch is the following one:

commit b9bf1e60a294fc7795d5198f94a917290e52865b
Author: John W. Linville <linville@tuxdriver.com>
Date:   Tue Aug 7 16:33:15 2007 -0400

    [PATCH] mac80211: probe for hidden SSIDs in pre-auth scan
    
    Probe for hidden SSIDs if initiating pre-authentication scan and SSID
    is set for STA interface.
    
    Signed-off-by: John W. Linville <linville@tuxdriver.com>

diff --git a/net/mac80211/ieee80211_sta.c b/net/mac80211/ieee80211_sta.c
index 7ba352e..0d99b68 100644
--- a/net/mac80211/ieee80211_sta.c
+++ b/net/mac80211/ieee80211_sta.c
@@ -2154,7 +2154,11 @@ static int ieee80211_sta_config_auth(struct net_device *dev,
 		return 0;
 	} else {
 		if (ifsta->state != IEEE80211_AUTHENTICATE) {
-			ieee80211_sta_start_scan(dev, NULL, 0);
+			if (ifsta->auto_ssid_sel)
+				ieee80211_sta_start_scan(dev, NULL, 0);
+			else
+				ieee80211_sta_start_scan(dev, ifsta->ssid,
+							 ifsta->ssid_len);
 			ifsta->state = IEEE80211_AUTHENTICATE;
 			set_bit(IEEE80211_STA_REQ_AUTH, &ifsta->request);
 		} else

-- 
Uli Kunitz

Re: [RFC] mac80211: fix software decryption with b43legacy

[Larry Finger]

Ulrich Kunitz wrote:
> Larry Finger wrote:
> 
>> I have added the lists to this message.
>>
>> I got b43legacy up and running with the software decryption modifications. 
>> It started OK with WPA-PSK TKIP encryption, but soon thereafter, I got this 
>> message:
>>
>> eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out of range
>>
> 
> Since the git tree reorg wireless-dev branch created comparable
> problems for zd1211rw-mac80211 too. It might be related:
> 
> Aug 19 07:08:51 keks kernel: [   83.572628] wlan0: CCMP replay detected for RX frame from 00:04:0e:68:ad:70 (RX PN 00000000000c <= prev. PN 00000000000c)
> Aug 19 07:08:54 keks kernel: [   87.432010] usb 1-2: handle_regs_int() regs interrupt ignored
> Aug 19 07:08:55 keks kernel: [   87.898447] wlan0: No ProbeResp from current AP 00:04:0e:68:ad:70 - assume out of range
> Aug 19 07:08:55 keks kernel: [   87.899649] wmaster0: Removed STA 00:04:0e:68:ad:70
> Aug 19 07:08:55 keks kernel: [   87.901406] wlan0: set_encrypt - unknown addr 00:04:0e:68:ad:70
> 
> The first message might be a simple duplicate. The
> handle_regs_int() is absolutely suspicious and I cannot really
> explain it right now. The "No ProbeResp" might be a follow-up
> problem. The whole USB subsystem becomes absolutely instable to
> the point that I can't use keyboard and mouse anymore. 
> 
> I will try Johannes' patch tomorrow.
> 
> BTW the wireless-dev reorg makes it impossible to actually use
> git-bisect to find the patch, which caused the problem. 
> 
> BTW the current Linus tree following patch doesn't work with the
> current zd1211rw-mac80211. The offending patch is the following one:
> 
> commit b9bf1e60a294fc7795d5198f94a917290e52865b
> Author: John W. Linville <linville@tuxdriver.com>
> Date:   Tue Aug 7 16:33:15 2007 -0400
> 
>     [PATCH] mac80211: probe for hidden SSIDs in pre-auth scan
>     
>     Probe for hidden SSIDs if initiating pre-authentication scan and SSID
>     is set for STA interface.
>     
>     Signed-off-by: John W. Linville <linville@tuxdriver.com>
> 

This patch is not in my tree, but adding it breaks WEP. WPA fails with it in or out at the moment. 
I'm still looking at that problem.

Larry

Re: [RFC] mac80211: fix software decryption

[Larry Finger]

Johannes Berg wrote:
> When doing key selection for software decryption, mac80211 gets
> a few things wrong: it always uses pairwise keys if configured,
> even if the frame is addressed to a multicast address. Also, it
> doesn't allow using a key index of zero if a pairwise key has
> also been found.
> 
> This patch changes the key selection code to be (more) in line
> with the 802.11 specification. I have confirmed that with this,
> multicast frames are correctly decrypted and I've tested with
> WEP as well.
> 
> While at it, I've cleaned up the semantics of the hardware flags
> IEEE80211_HW_WEP_INCLUDE_IV and IEEE80211_HW_DEVICE_HIDES_WEP
> and clarified them in the mac80211.h header; it is also now
> allowed to set the IEEE80211_HW_DEVICE_HIDES_WEP option even if
> it only applies to frames that have been decrypted by the hw,
> unencrypted frames must be dropped but encrypted frames that
> the hardware couldn't handle can be passed up unmodified.
> 
> Support for group keys in IBSS mode is pending until we figure
> out how to handle that. It will also, like with VLANs, require
> a hardware encryption API change.
> 
> Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
> 
> ---
> Michael, you should really get rid of IEEE80211_HW_DEVICE_HIDES_WEP
> in b43, otherwise you'll have to start dropping unencrypted
> frames and handle 802.1X callbacks and stuff to guarantee
> proper operation.
> 
> I would be much in favour of removing the option completely,
> it's IMHO misused in b43 and no other driver uses it.
> 
> Volker, can you test whether this patch (possibly together with
> yours removing privacy and key index checking) helps with your
> dynamic WEP? I think it should.
> 
> Larry, could you verify that this gets rid of your messages? It
> does for me but then I'm using CCMP and not TKIP so maybe there's
> something special again.

Using the large patch you sent me plus the one that fixed the crash due to usage after freeing, I 
can now connect using both WPA and WEP. My settings for the hw->flags is

        hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
                     IEEE80211_HW_DEVICE_HIDES_WEP | IEEE80211_HW_WEP_INCLUDE_IV;

With WPA, I no longer get those messages; however, I get a lot of those "No ProbeResp" messages with 
a subsequent reassociation rather often as shown in my log fragment below:

Aug 20 23:49:21 larrylap kernel: eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out 
of range
Aug 20 23:49:22 larrylap kernel: eth1: No STA entry for own AP 00:1a:70:46:ba:b1
Aug 20 23:49:22 larrylap kernel: eth1: Initial auth_alg=0
Aug 20 23:49:22 larrylap kernel: eth1: authenticate with AP 00:1a:70:46:ba:b1
Aug 20 23:49:22 larrylap kernel: eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 
status=0)
Aug 20 23:49:22 larrylap kernel: eth1: authenticated
Aug 20 23:49:22 larrylap kernel: eth1: associate with AP 00:1a:70:46:ba:b1
Aug 20 23:49:22 larrylap kernel: eth1: RX ReassocResp from 00:1a:70:46:ba:b1 (capab=0x431 status=0 
aid=1)
Aug 20 23:49:22 larrylap kernel: eth1: associated
Aug 20 23:50:23 larrylap kernel: eth1: No ProbeResp from current AP 00:1a:70:46:ba:b1 - assume out 
of range
Aug 20 23:50:24 larrylap kernel: eth1: No STA entry for own AP 00:1a:70:46:ba:b1
Aug 20 23:50:24 larrylap kernel: eth1: Initial auth_alg=0
Aug 20 23:50:24 larrylap kernel: eth1: authenticate with AP 00:1a:70:46:ba:b1
Aug 20 23:50:24 larrylap kernel: eth1: RX authentication from 00:1a:70:46:ba:b1 (alg=0 transaction=2 
status=0)
Aug 20 23:50:24 larrylap kernel: eth1: authenticated
Aug 20 23:50:24 larrylap kernel: eth1: associate with AP 00:1a:70:46:ba:b1
Aug 20 23:50:24 larrylap kernel: eth1: RX ReassocResp from 00:1a:70:46:ba:b1 (capab=0x431 status=0 
aid=1)
Aug 20 23:50:24 larrylap kernel: eth1: associated

Thanks,

Larry

Re: [RFC] mac80211: fix software decryption

[Johannes Berg]

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

On Mon, 2007-08-20 at 23:59 -0500, Larry Finger wrote:

> Using the large patch you sent me plus the one that fixed the crash due to usage after freeing, I 
> can now connect using both WPA and WEP. My settings for the hw->flags is
> 
>         hw->flags = IEEE80211_HW_HOST_GEN_BEACON_TEMPLATE |
>                      IEEE80211_HW_DEVICE_HIDES_WEP | IEEE80211_HW_WEP_INCLUDE_IV;

Neither of those actually matter for b43legacy, but that's ok.

> With WPA, I no longer get those messages;

Great :)

>  however, I get a lot of those "No ProbeResp" messages with 
> a subsequent reassociation rather often as shown in my log fragment
> below:

That's a bit strange. I don't see right now how my patches could be
causing it but I'll look into it.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]