Michael Buesch wrote:
Well. Works For Me (tm). If there is some bug for you in current mainline, it needs to be fixed. But I can't fix something I am not able to reproduce and don't know what happens.
Take a look at the logs in Ben's original mail. I've seen this a lot myself and am fairly sure that the problem is softmac's handling of a SIWESSID *immediately* followed by a SIWAP call. This is what wpa_supplicant does, and the timing screws us over.
You can see in the logs that the driver starts authenticating after the first ioctl comes in, but then starts scanning (in preparation for authentication, again) as soon as the 2nd call comes in immediately after. As the device is busy scanning other channels it misses the authentication response, and this goes round in circles.
Now, Jose recently bolted on a few more lock-like flags onto the whole auth+assoc procedure, which has certainly helped, but the races do still exist, and I don't think that approach is practical: there are simply too many points in the sequence where softmac could be 'interrupted' by another ESSID/AP call.
But, I'd be absolutely delighted if I'm missing something and you can fix it :)
Daniel - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
