Bugzilla – Bug 1035
can't directly associate with shared-key AP when setting current key [2] ,[3] or [4]
Last modified: 2006-05-23 01:20:24
You need to log in before you can comment on or make changes to this bug.
Environment (distro, kernel, driver, daemon): SUSE10 ,kernel-2.6.15.3,ipw3945-1.0.3 ieee-1.1.13,ipw3945d-1.7.18 ipw3945-ucode-1.13 Problem description:set 64-bit shared key on AP , key1 1111-000-000 key2 2222-000-000 key3 3333-000-000 key4 4444-000-000 set current active key is [2] ,[3] or [4] on AP then associate to AP,the association would be failed. if you set current active key to [1] , the association can be set up, and then change the active key to [2],[3] or [4] the association also can be successful. steps to reproduce: %set current active key index to [2] %./load debug=0x43fff %iwconfig eth1 essid ipwdebug %iwconfig eth1 key [2] %iwconfig eth1 key 2222 restricted %iwconfig eth1 --> shows unassociate with AP this bug can be reproduced both on a-band and b/g band. I have tested with linksys and netgear AP, there is the same problem.
Created an attachment (id=795) [details] dmesg log
Created an attachment (id=796) [details] debug=0x43fff
(From update of attachment 795 [details]) dmesg log with default debug level
Created an attachment (id=797) [details] patch to try
change status
With this patch ,the driver works well ,association can be set up with any active key .
Merged into GIT. Will be in next snapshot.
Tested on ipw3945-1.0.5 ,the DUT can directly associate with any active key index. Setting as verified.