Bugzilla – Bug 572
Cannot associate with AP (disassociates after AUTH_SEQ_1)
Last modified: 2005-10-06 15:59:23
You need to log in before you can comment on or make changes to this bug.
I cannot associate with the AP at my university. It runs at 801.11b and has quite a low signal strength (35 reported by windows driver in ndiswrapper). I have attached the logs. As you can see it disassociates right after recieving a notification with AUTH_SEQ_1 set. But it does work with the ndiswrapper, so it has to be either a firmware or a driver problem. There was a thread on the mailing list discussing the problem, but there was just one response from the developers, which did not resolve the problem. I classified this bug as critical, because it prevents me from using the wireless network, which is the purpose of the driver.
Created an attachment (id=264) [details] Kernel log with debug mask = 255
I have found the cause of the error. It is not the ipw2200 driver, but the Gentoo specific wireless scripts, which "somehow" cause this behaviour.
could it be reopened ? i narrowed the bug, and it is ipw2200 fault (not gentoo's scripts). if you execute the following commands: iwconfig eth1 txpower auto (the time between the 2commands doesn't matter) iwconfig eth1 mode auto the card cannot associate anymore (with the symptoms described in the previous comments - AUTH_SEQ_1). It is interesting to note that when you run the two commands in the reverse order but it as to be quick (like command1 ; command2), the card will fail too. Hope it helps, Benoit
Does the problem still exist on 1.0.3? If 1.0.3 still has the problem, please try the patch in bug 455. http://www.bughost.org/bugzilla/attachment.cgi?id=341&action=view
For me the bug is resolved in 1.0.3, I'll leave it up to you to close the bug.
1.0.3 fixes this
fixed in 1.0.3
I am having the problem with 1.0.3 (gentoo, Dell D600), and the patch does not fix it. I can provide more info if needed. regards, Benoit.
Benoit, please provide dmesg with debug=255 for the patched 1.0.3 driver.
Created an attachment (id=371) [details] kernel log with debug = 255 Kernel log while issuing the commands : iwconfig eth1 txpower auto iwconfig eth1 mode auto
Created an attachment (id=374) [details] fix iwconfig txpower auto iwconfig will pass -1 if txpower auto is used, this decrease the tx power for the device. Please try this patch and see if it fixes the bug.
It fixes it (with or without the patch in bug #455). Thanks, Benoit
mark as fixed
Created an attachment (id=377) [details] a better fix I'll check in this fix to next release.
The patch is in 1.0.4.
*** Bug 632 has been marked as a duplicate of this bug. ***
Created an attachment (id=390) [details] Correctly merges chuyee's patch into 1.0.4 vs. what actually made it into the build In addition to fixing what this bug was originally about, chuyee's patch also fixes support for 'txpower auto' to actually set the power level to a default, which allows us to support that parameter as well (fixing #632)
*** Bug 668 has been marked as a duplicate of this bug. ***
There seem to be several different interpretations of what settings txpower to auto should do. a) from iwconfig(8) in wireless-tools-27: In addition, on and off enable and disable the radio, and auto and fixed enable and disable power control (if those features are available). b) chuyee's patch: choose a reasonable default c) Planet WL3501 driver in my 2.6.11 (gentoo) source tree reports fixed=0, because txpower is configurable (not fixed). Other drivers in the kernel tree don't support txpower, can't change it, or simply ignore fixed. I think we need some clarification as to which interpretation is correct (after all, wireless extensions should be consistent across drivers).