Is the MIC of EAPoL-Key (2/4) affected by the .11 driver?

[Ali Bahar]

Hi all,

is the MIC of EAPoL-Key (2/4) affected by the 802.11 driver, or is it
solely calculated by the supplicant?

I am getting a "Michael MIC failure" from the AP, and am wondering if
the device driver code plays any role in this, or whether this is
solely affected by the supplicant. I expected only the latter, but I
have not found any other culprits for the failure!

More info:
I am running wpa_supplicant (version 0.8, development snapshot) to
connect to an AP via WPA1/WPA2. The first EAPoL-Key packet (1/4) comes
through, but the second one (2/4, sent from the STA/client) is
followed by a Disassociation from the AP. The Reason Code for the
latter is "Michael MIC failure".
I have tried both WPA1 and WPA2, using wpa_supplicant's own example
settings.
Without encryption, the client associates, and transmits data,
properly. 
The driver is rt2800usb, from wireless-testing 3.0.0-rc2. I have tried
an rt2800pci device as well.

Yet more info:
AFAIK only the supplicant is responsible for the building of the EAPOL
pkt. The .11 driver is mere transport for it. So the under-development
status of the driver code ought not be a factor.
In the initial runs, the kernel had little-to-no crypto support. That
ought not have been a factor at _this stage_; indeed, a new kernel,
with full crypto support, produced the same result.

NB Yes, I _have_ sifted thru the gmane archives of this ML. A 2007
response by Jouni helped, but there are surprisingly-few posts related
to such a MIC failure!

Thanks much for any advice.
regards,
ali