NDIS driver / changing RSN IEs

[Bryan Kadzban]

Jouni Malinen wrote:
> This sounds like enabling/disabling WMM which uses four separate TX 
> queues.

Well, we've disabled WMM entirely, and we aren't changing that setting.
After doing some more testing, it seems that the number of replay
counters is 4 (both PTKSA and GTKSA) on an AP booted with our config.
After changing the DTIM interval from 2 to 5 on the CCMP SSID, the
number of replay counters drops to 1 (for both PTKSA and GTKSA).
Setting the DTIM interval back to 2 does not change the number of replay
counters, either.  After the next AP boot, the number of replay counters
does reset to 4.

Cisco's still working on the issue.  I suspect a bug in their firmware,
but they may say "the standard says that as long as our beacons and
probe responses are the same as our 4-way handshake IEs, we're OK".  And
they'd be perfectly OK to do so.

> wpa_supplicant should ask the driver for the IE after each
> association.

I don't know whether it does for sure or not, but I don't believe so.
I'll see if I can find out from the log (or maybe I'll just edit
driver_ndis to wpa_printf something when the IE OID is requested), and
if I find anything helpful, I'll send the info tomorrow.

> I haven't tested this, but if this is not the case, wpa_supplicant 
> should be fixed to do this. However, this is not enough, since also
> the NDIS driver has to update its BSSID list to include the latest
> WPA/RSN IE.

OK, we also run a different program that I've written, which does a list
scan on startup, then gets the scan results every second and puts them
in a grid on the screen.  (This is because these machines will be used
by people that will change anything we let them change, and most
wireless vendors' utilities allow any user to change everything -- SSID,
PSK, EAP credentials, anything.  So we wrote our own, which was pretty
much read-only.)

With all drivers that we use, the associated BSSID updates at least some
pieces of information (signal strength is what we're mostly looking at)
every second.  With some drivers, the other BSSIDs that are in range
update also.  The driver for the WMP54GS rev 1.1 card that we use for
testing *does* update the non-associated BSSIDs' signal strength.

I don't look at the IEs in this program, though.  Maybe they don't
change even though the signal strength does.  I should probably start
looking at them.

Anyway, what I'm saying is, all the drivers that we use show some kind
of update on at least one BSSID without a scan.

>> 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.
> 
> Hmm.. "wpa_cli scan" should not break association; NDIS spec requires
> that scan request can be issued at any time.. Do you mean that the 
> driver refuses to reconnect to the AP or that wpa_supplicant does not
> allow the authentication after this?

I'm not exactly sure anymore -- I know authentication was broken after
the scan, and I'm fairly sure the association was too.  Bug in Linksys's
driver?  (Though I think it happened with D-Link's latest DWL-G520 rev B
driver also.)

However, my wireless monitor program also sends an NDIS scan request
whenever one of its buttons is clicked, and that does not break the
association or prevent subsequent (re)authentications.

(I think the problem was actually ap_scan=2 interfering with some of the
code in wpa_supplicant, but I'm not sure.)

> The problem here seems to be in getting the driver to update its
> BSSID table.

Yes, I'd probably agree with that (though I do still want to look at the
logs).

> Likewise, I've seen at least some vendors improving on this area over
> time, so updating to the latest driver may also help with this.

There is only one driver for the WMP54GS rev 1.1 cards, so we've done
that already.  ;-)

> You can send longer logs directly to my email address, if needed.
> NDIS driver not updating BSSID data is not really a supplicant issue,
> so that is somewhat less interesting for me, but if the "wpa_cli
> scan" is triggering wpa_supplicant to do something incorrectly, that
> should be fixed.

OK, I'll try to reproduce that tomorrow as well, and depending on the
log, I'll send it somewhere (either here, or to your address).

>> 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.)
> 
> Those replay counters are not really used for anything in the 
> supplicant.

I figured they probably weren't, but I didn't know for sure.  I assume
they're something that the supplicant could use if it wanted to?

I wasn't sure what else the IEs might have been used for, though, so I
didn't want to modify them in-place.

>> 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?
> 
> Doing this kind of masking of the IEs is against the standard, but I 
> don't see it causing any security problems, so it should be fine as a
> workaround for the driver not updating BSSID data.

Hmm, OK.  I'd rather fix the issue than keep this workaround, I think.

> The APs are allowed to change WPA/RSN IE. Though, I have to admit it
> is somewhat surprising thing to do if you did not change
> configuration (disabled/enabled WMM) at that point.

Nope, we only changed the DTIM interval.  (This did reset the radio,
though, so that may possibly be related.)

> WPA/RSN IE is just used to advertise how many replay counters are 
> supported. WMM needs four (i.e., one for each TX queue).

Ah, OK, that makes sense.

> The proper fix for the issue would be to fix the NDIS driver to
> update its BSSID data to match with the latest Beacon/ProbeRsp frames
> received from the AP.

Yes, that sounds about right.  I have a few different things to look at;
I'll post back tomorrow.

Thanks a ton!
-------------- 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/20051106/a20c145b/attachment.pgp