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=lnkkid=120709bid=263057dat=121642
___
Zd1211-devs mailing list - http://zd1211.ath.cx/
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/zd1211-devs
