NDIS driver / changing RSN IEs

[Bryan Kadzban]

Bryan Kadzban wrote:
> Jouni Malinen wrote:
>> 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.

OK -- after looking at driver_ndis.c a bit more, it looks like it
doesn't actually report the beacon IEs on an association-info event.
When the driver associates, it generates an NDIS media-connect event,
which ends up calling into wpa_driver_ndis_event_connect (assuming
ndis_events is running).

That function calls wpa_driver_ndis_get_associnfo, which is supposed to
report the various IEs back to the rest of the code.  But that function
only does a get_oid on OID_802_11_ASSOCIATION_INFORMATION, which does
not include the beacon or probe response IEs.  (That information is
available from OID_802_11_BSSID_LIST, though it may not be the most
recent scan.)  It zeroes out the wpa_event_data union, then sets its
assoc_info.req_ies and assoc_info.resp_ies (and the corresponding
lengths), but it never does anything with the assoc_info.beacon_ies.

I added code to request OID_802_11_BSSID_LIST, then iterate through the
results looking for a result that has a BSSID matching drv->bssid.  When
I find the first one, I check its ->IELength and make sure that's bigger
than the size of the NDIS_802_11_FIXED_IEs structure.  Then I set
assoc_info.beacon_ies to ->IEs + sizeof(NDIS_802_11_FIXED_IEs), and I
set assoc_info.beacon_ies_len to ->IELength - sizeof(that-structure).

Then I call wpa_supplicant_event(..., EVENT_ASSOCINFO, ...);.

This works fine -- the WMP54GS driver does update its BSSID list soon
enough after an association that we've never gotten the old IEs.

I would send a patch, but since I made the changes while at work, I'm
not entirely sure who owns them.  If you can't reimplement the changes
based on this description, let me know and I'll see if I can get them to
release it under a dual-BSD-GPL license, to match wpa_supplicant.

>> 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.)

Yes, it looks like the problem was ap_scan=2.  I've looked at the log
again, and the problem is almost assuredly due to driver_ndis.c (yes,
this issue too).  I've attached a gzipped log.

When wpa_supplicant.c calls wpa_drv_scan, that ends up calling into
wpa_driver_ndis_scan.  That function checks drv->radio_enabled, and if
that flag isn't set, it calls wpa_driver_ndis_disconnect (which sets the
current SSID to a 32-byte random value).

When wpa_supplicant is configured in ap_scan=2 mode and using the NDIS
driver, wpa_driver_ndis_scan never gets called on startup.  Instead, the
code just associates with the first SSID in the config file.  (In
ap_scan=1 mode, wpa_supplicant does indeed call wpa_drv_scan during its
startup.)  So when the control interface requests a scan, radio_enabled
is 0, because the driver was never told to scan the first time around.

So the first control interface scan ends up setting the SSID to a random
string.  (In the log, this is the point where it says "NDIS: turning
radio on before the first scan", line 549.)  This is what breaks the
association, and I'm pretty sure it's also what causes all the failures
later.

One possible fix might be to find somewhere else in driver_ndis.c to set
drv->radio_enabled, so that it gets set no matter what the ap_scan mode
is.  I haven't tried this, but I'm guessing it'd work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log-scan.txt.gz
Type: application/gzip
Size: 7956 bytes
Desc: not available
Url : http://lists.shmoo.com/pipermail/hostap/attachments/20051107/201e78e3/attachment.bin 
-------------- 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/20051107/201e78e3/attachment.pgp