Opportunistic Key Caching on wpa_supplicant

[Matt Causey]

On Wed, Sep 21, 2011 at 5:29 PM, Jouni Malinen <j at w1.fi> wrote:
> On Wed, Sep 21, 2011 at 05:05:59PM -0400, Matt Causey wrote:
>> > Which WLAN driver are you using? If the 0.8.x snapshot does not fix
>> > this, please provide verbose debug log from wpa_supplicant (-ddt on
>> > command line; or -ddKt if this is a test network and you don't care
>> > about revealing passwords/keys etc. private information).
>
>> We're running with -onl80211, using the vanilla ath9k code in our
>> kernel version.
>>
>> This version seems to roam flawlessly. ? How much testing has this
>> version of code seen?
>>
>> Just FYI, I've posted the output from out controller below, in case it
>> is helpful.
>
> Interesting.. It is unclear from those logs what exactly was causing the
> problem in 0.7.3. The fixes I've done in 0.8.x branch should have
> addressed somewhat different issues.
>

Hum.  Well since you said that, I decided to test _again_ with the
latest stable, and I cannot reproduce the problem.

So, to fill in some detail that I left out initially, I did have this
work on the latest stable, but something changed and fast roaming
stopped working.   Restarting the daemon and various other steps would
not cause it to work again.  And now that I've gone back to test, it's
working again...on the old code.  It makes me sad that it is
inconsistent and I don't know what variable is changing.  It's not
even clear if it is the controller failing or the supplicant.

In the middle of writing this I moved the client around to cause a
roam and it re-auth'd with RADIUS....so I'm seeing some sort of
inconsistent failure of fast roaming.  Here is what the supplicant
says:

Setting authentication timeout: 70 sec 0 usec
RSN: Authenticator did not accept PMKID, doing full EAP authentication
EAPOL: Supplicant port status: Unauthorized

Is it possible that the PTK sent by the supplicant and received by the
controller gets malformed somehow?  I'll keep running tests to see if
I can repro more failures, possibly getting some 802.11 captures.
I'll also re-try the new code, but will let it run longer this time
before proclaiming success this time.  :-)

> As far as testing of the current snapshot of the development branch is
> concerned, that specific version is unlikely to have received much
> testing since there was a change there today ;-). In general, I would
> expect 0.8.x branch to be in much better shape as far as use of nl80211
> and roaming is concerned.
>

Well, sure you're making a lot of changes in the current snapshot.
:-)  But more generally....what does the regression test procedure
look like for the supplicant?  I'm just curious...  :-)

--
Matt