Jouni Malinen wrote:
> On Mon, Feb 21, 2005 at 06:09:52PM +0100, Ajeet Nankani wrote:
>>>>what i understood by going through old mails on the above issue, that
>>for pre-authentication to work, STA needs to have the new AP in the scan
>>resutls at both times, one when it pre-authenticates with the new AP
>>through the current AP and when it actually associate and do 4 way
>>handshake with new AP, is it true?
>>> Well, in many cases, yes, but this is not really a requirement.
> Something needs to trigger the station to believe it should
> pre-authenticate with an AP. This may indeed be scan results showing
> another AP with pre-authentication enabled; or it could also be report
> from the current AP listing potential neighbors. As far as
> wpa_supplicant is concerned, scan results would not be needed for either
> when ap_scan=2 mode is used, but the driver will most likely have these
> results internally even in this case.
>The main task, for taking full advantage of pre-authentication, actually
is the building of that neighbours-list(BSSIDs, RSN IE or just
Capabilities block?? or just pre-authentication flag??) and transfering
of that list from AP to Associated STAs.
IAPP cant help here as its neighbours lists contains only BSSIDs, and
for pre-authentication we need BSSIDs and atleast pre-authentication flag.
But in senarios where we know that all AP supports RSN and
pre-authentication(like in corporate and campus networks) then we could
exploit even that IAPP neighbor list by forcing wpa_supplicant to
pre-authenticate with APs in the list, but again the problem is how to
transfer that list from AP to STA??
For Jouni and other developers, can we use one of the reserved subtypes
in mangement frame and transfer the list through that/those frame/frames
to STA?.....or may be built new IE...just a thought. Ofcourse we have to
modify AP and STA to handle that management frame or IE accoringly. But
is it possible to modify hostap to accomplish above task??
-ajeet.