[Q] NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION and NDIS_STATUS_DOT11_CONNECTION_COMPLETION (Plain Text

NTDEV
1

Hi!

Reposting in plain text just to make sure this magnus opus gets out…

Hi!

We’re seeing a problem a connection to an AP is taking too long when the STA
roams to the AP following a resume to D0. In this case, the NWF driver
detects the loss of connection to its first AP (AP1) and makes an
NDIS_STATUS_DISASSOCIATION indication. It then roams to AP2.

We have an OEM client that has a tool that measures the time between
resuming to D0 to acquiring an IP address from AP2. They want the reconnect
time to be less than 2.5 seconds. However, we see times much larger than
this when the STA associates in WPA/WPA2. We don’t see this type of delay
when the STA associates in open.

When the STA associates to AP2 with WPA/WA2, I see the following:

  1. The STA makes an NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION indication
    followed almost immediately by an NDIS_STATUS_DOT11_CONNECTION_COMPLETION.
    The last indication is a trigger to the upper-layer protocols (ULPs) to
    start sending non-exempted Class 3 data packets.

I believe (but need to confirm) that the
NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION indication is a trigger to the host
supplicant to perform the 4-way handshake to resolve the pairwise key. If
so, it should be possible for the driver to get exempted EAPOL packets
before the driver makes the NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION
indication.

  1. The TCP/IP stack sends down a DHCPREQUEST before the key material is
    plumbed to the driver. This packet is rejected because it can not be
    encrypted. While I see this packet on a Wireshark trace on the DUT, the
    driver does not get this packet. So, I assume that the NWF interface itself
    is discarding the packet.

  2. The key material is plumbed down to the driver.

  3. The TCP/IP stack retries the DHCPREQUEST 4 or more seconds after item #3.
    This request succeeds because it can be encrypted and the DHCPACK from the
    AP can be decrypted. Thus, the interface’s IP address is resolved.

The question really is “Should we hold off on making the
NDIS_STATUS_DOT11_CONNECTION_COMPLETION until we have the keys plumbed down
through OID_DOT11_CIPHER_DEFAULT_KEY and OID_DOT11_CIPHER_DEFAULT_KEY?”. If
we delay the indication, we avoid non-exempt packet rejection because cipher
keys are not yet available.

Naturally, waiting for DHCP to retry is the DHCPREQUEST or DHCPDISCOVER can
result in a significant delay. If the driver can simply throttle
non-exempted data packets from coming down by simply delaying the
NDIS_STATUS_DOT11_CONNECTION_COMPLETION until the key material is plumbed,
that would remove this delay and decrease the reconnect times.

The WDK is a bit vague about this, but the Port Creation topic
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff570185(v=vs.85).aspx)
implies that 802.1x packets can be sent or received through the driver after
NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION is made.That means the driver
should be able to send/receive exempt EAPOL packets before it makes the
NDIS_STATUS_DOT11_CONNECTION_COMPLETION indication.

This last point in clarified in the
NDIS_STATUS_DOT11_ASSOCIATION_COMPLETION
(http://msdn.microsoft.com/en-us/library/windows/hardware/ff567319(v=vs.85).aspx):

“Be prepared to send and receive packets. If the 802.11 station performed
the association operation within the context of either a connection or
roaming operation, the miniport driver must be able to send or receive
packets before it makes the NDIS_STATUS_DOT11_CONNECTION_COMPLETION or
NDIS_STATUS_DOT11_ROAMING_COMPLETION indications.”

So, can someone answer whether it is valid for the driver to hold off on the
NDIS_STATUS_DOT11_CONNECTION_COMPLETION indication until after it gets the
cipher keys?

Thanks, and sorry for the reposting!