Remco wrote:
Are you saying that softmac does the association on behalf of wpa_supplicant ?


Yes - wpa_supplicant doesn't really have much say in the process. All it does is use WE to request association, and transmit and receive data frames, as well as set the encryption parameters once those have been negociated.

I'd expect something like this:
- softmac does authentication and association for open / shared, unencrypted / WEP encrypted networks. - With WPA involved I expect softmac to authenticate, but since the association is different I expect wpa_supplicant to associate and inform softmac to update its association state once wpa_supplicant is done.

I don't know enough about WPA to say for sure, but I don't think the association is any different. The association definitely happens through the standard WE interface. The MLME is implemented fully in the kernel, and although it will be pushed out to userspace at some point, thats not the case just yet.

I think the way it works is like WEP: You can associate openly, but thats where the line is drawn, you are effectively useless on the network unless you are able to understand the encryption challenges which happen next, and eventually you end up with an encryption key which you use to decrypt all future data frames.

By just looking at the logs it seems either softmac associates on behalf of wpa_supplicant not giving wpa_supplicant a chance to do its thing or wpa_supplicant fails to do its thing and doesn't report failure to softmac leaving softmac to belief we've got an association.

I think the channel cycle after initial association causes the driver to miss the WPA challenge traffic. I can reproduce this here, if I do not load the appropriate encryption modules (the access point deauthenticates us, but the driver is too busy on other channels to see that happen). That's my best guess at your problem right now - I don't know if its the actual cause or not, but I'm not able to investigate further until I can get it working flawlessly for myself.

The softmac automatically scans / associates thing feels bad to me. It gives me the feeling wpa_supplicant is left out of the equation at some point.

I don't fully understand it, but I think this is a limitation of WE, because it doesn't even have a loose form of atomic association requests. When the initial association ioctl happens, softmac is not aware if wpa_supplicant will feed more specific details on the request after, so it just starts associating right away. We are discussing this on the linux-netdev list.

Also the associate once / associate again feels bad, I thought association is necessary only once.

Correct, this is softmac getting confused... The WE interface is hard to implement perfectly in softmacs current model, I haven't figured out how we're going to be able to support it better just yet.

Daniel


-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs

Reply via email to