NDIS driver / changing RSN IEs

[Bryan Kadzban]

Bryan Kadzban wrote:
> So the problem is still there, but the problem isn't that
> set_ap_rsn_ie doesn't get called.  The problem is that the scan
> results table is out of date, and it returns the wrong IE.
> 
> I have tried doing a "wpa_cli scan" while the supplicant is in this 
> state (to update the scan results table), but that refuses to ever 
> reconnect to the current AP, for some reason.  I believe it's an
> issue with the NDIS driver in use (Linksys's driver for their WMP54GS
> cards), but I don't know that for sure.

I've since tried a couple things.  Using ap_scan=1 instead of 2 makes
scanning not kill the connection at least -- although after some
consideration, I think scanning every few minutes is probably not a
great way to fix this issue.

Since the changing value is always the RSN capabilities field, and
always the number of PTKSA/GTKSA replay counters, I changed the code to
zero out those replay counter bits in both IEs just before it does its
memcmp.  (I actually made a copy first, because I'm not sure what else
those pointers are used for.)  This does work -- the client does come
back after an AP restart changes that value.

Does this have any security implication?  I don't think so (especially
since I left the rest of the capabilities field as-is), but I don't know
for sure; maybe someone else here does?

It's also only a temporary workaround, I think, until we can fix our APs
to not change that IE.  But still, I'm not sure what the implications
are security wise.  (I don't really completely understand what those
replay counters do -- just watch for reused IVs?  then why would you
need more than one per PTKSA?)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20051103/f004854a/attachment.pgp