NDIS driver / changing RSN IEs

[Bryan Kadzban]

We are using the NDIS backend driver with wpa_supplicant on several
Windows 2000 Pro machines.  Our APs are Cisco 1121 and 1231s.

At times, when we reset the radios on these APs (for instance, when the
AP restarts, or when we change a setting on the relevant SSID / virtual
BSSID), the "RSN capabilities" field in the RSN IE in the beacons and
probe responses will change.  I've seen these APs go from advertising 1
PTKSA counter/1 GTKSA counter to 4 of each, and sometimes they go from 4
to 1.  It's (so far) always either 4 or 1, though, and the PTKSA counter
count is always the same as the GTKSA counter count.

This is a problem if one of these wpa_supplicant machines is connected
at the time of the radio reset.  After the AP comes back up, the
supplicant will start making the connection "bounce" up and down.  It's
trying to associate with the AP whose IE just changed, and it'll get all
the way through association into the 4-way handshake, but when it
receives frame 3 (the one containing a copy of the AP's RSN IE), it will
reject the AP because the capabilities field is different.  (At least,
according to the debug log, that's what's happening.  I've attached a
gzipped -ddt log file showing the issue.)

But the IE isn't different from the beacons and probe responses that the
AP has been sending ever since its radio reset; the supplicant is using
an old copy of the AP's RSN IE.

I believe it is legal (according to 802.11i) for an AP to change its RSN
IE like this, as long as it can inform clients of the new IE.  But I'm
not sure; maybe it is invalid.

How can I either clear the stored AP RSN IE, or update it with the
current probe response / beacon frames' contents?  Is it possible at all
using the control interface?  Or is it possible with NDIS somehow?  (I
remember a similar issue we had a while ago, where the supplicant wasn't
resetting its 4-way handshake replay counters when it reassociated.
Looking at the source code, I figured out that the supplicant's counters
should have been reset whenever it got an NDIS media-connect event, but
we weren't running ndis_events.exe.  So we started running ndis_events,
and it worked fine.  But this problem is still happening -- is there
something similar we can be doing to clear the AP's RSN IE?)

I'm planning on creating a tech support request with Cisco later today,
but I want to ask the people behind both "ends" of the connection, to
see whether I can get a fix from either side.

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.txt.gz
Type: application/x-gunzip
Size: 7693 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20051031/53c5770e/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20051031/53c5770e/attachment.pgp