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
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
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)
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
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 <[email protected]>
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 <[email protected]>
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
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 <[email protected]>
> 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 <[email protected]>
>
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