On Sunday 24 September 2006 17:34, Daniel Drake wrote: > 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 :)
Ok, thanks for the explaination. I will look into the issue. I remember seeing racing wext calls, too. -- Greetings Michael. - 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
