IWEVPMKIDCAND Event

[Jouni Malinen]

On Thu, Aug 27, 2009 at 11:26:49AM +0530, Paresh Sawant wrote:

> Since we have provision in wpa_supplicant code to handle IWEVPMKIDCAND
> event, we must have tested that with some hardware/driver combination,
> right ? is it possible to share information on those hardware/drivers
> ?

Well, that is assuming quite much.. The PMKID candidate event is mainly
to support NDIS drivers, i.e., less frequently used on Linux. In theory,
you could use this with ndiswrapper and an NDIS driver that is the
actual source of the event. I don't know whether anyone has tested that.
In addition, rndis_wlan driver does have code for emitting this event
(again, due to its NDIS-like nature). Just like with ndiswrapper, I have
no idea whether someone has actually tested this.

> Is there a way to know beforehand at run time to know whether the
> driver supports IWEVPMKIDCAND event notification? If we could know
> that it does not support, then we could turn on 'ap_scan=1' during run
> time, and facilitate preauthentications with right candidates. The
> idea is to eliminate the race condition between event handlers for
> driver driven IWEVPMKIDCAND event and ap_scan=1 driven event.

I don't think there is any WEXT capability flag providing this
information.

> Why roaming is associated with IWEVPMKIDCAND ? IWEVPMKIDCAND is just
> to facilitate the preauthentication with the candidate access points,
> and that leads to pmksa caching and hence fast hand-off in case of
> roaming, right? correct me if I'm wrong in understanding.

RSN pre-authentication candidates are usually determined from scan
results and as such, this is very much related to scanning and roaming
in general. For the driver to be able to generate IWEVPMKIDCAND events,
it will need to be processing scan results (similarly, when ap_scan=1 is
used, wpa_supplicant can do the same processing internally and does not
need the additional driver event).

-- 
Jouni Malinen                                            PGP id EFC895FA