Share via

Receiving 802.11 Packets

  • Article

An 802.11 miniport driver emulates an 802.3 device. All packet data that the driver indicates with either the NdisMIndicateReceivePacketfunction or the NdisMEthIndicateReceivefunction must be in 802.3 format.

The device must replace the 802.11 MAC header with the appropriate 802.3 MAC header. Also, if the received packet data was encapsulated in RFC 1042 or IEEE 802.1h format, then the device must remove the LLC header and replace it with an Ethernet II header.

When indicating packet data, the 802.11 miniport must do the following:

  • If the driver is using NdisMIndicateReceivePacket to indicate received data, then the packet data requires an NDIS_PACKET descriptor from a preallocated pool managed by the driver. An NDIS_BUFFER descriptor is also used to access the driver's packet data buffer. For more information about the steps involved in indicating received packets, see Indicating Receive Packets with NdisM(Co)IndicateReceivePacket.

    For efficiency, each indicated NDIS_PACKET must have a single NDIS_BUFFER in its buffer chain. The driver must coalesce each MPDU fragment that it receives into a single data buffer that is linked by the NDIS_BUFFER descriptor. The driver must not scatter the MPDU fragment across multiple buffers.

  • If the driver is using TKIP for encryption, then it must first remove the 8-byte Message Integrity Code (MIC) checksum from the end of the packet payload.

  • If the driver is using any cipher suite, then the driver must do the following:

    • Remove any cipher headers that follow the 802.11 MAC header. For example, the driver must remove the WEP IV header or the TKIP IV / Extended IV header.
    • Remove any cipher checksum trailers at the end of each MPDU. For WEP and TKIP, this would be the 4-byte ICV trailer. For AES, this would be the 8-byte MIC trailer.
    • Not indicate the packet if the 802.11 device cannot decrypt it successfully.

  • The driver must indicate receive packets only if they satisfy the rules defined by the driver's current privacy filter. The privacy filter is set through OID_802_11_PRIVACY_FILTER.

  • If the driver is using the TKIP cipher suite and the MSDU data fails MIC verification, then the driver must not indicate the packet. If the driver is using the AES cipher suite and the MPDU data fails MIC verification, then the driver must not indicate the packet.

  • Whenever a MIC failure is encountered, the driver must make an authentication indication. Depending on which key was used to perform the MIC, the driver must set the Flags member of the NDIS_802_11_AUTHENTICATION_REQUEST structure to either NDIS_802_11_AUTH_REQUEST_PAIRWISE_ERROR or NDIS_802_11_AUTH_REQUEST_GROUP_ERROR.

If the driver is using the TKIP cipher suite, then it must support the TKIP countermeasures for integrity failures and do the following:

  • When detecting an integrity failure, the driver must make an authentication indication. Depending on the key used to detect the integrity failure, the driver must set the Flags member of the NDIS_802_11_AUTHENTICATION_REQUEST data to either NDIS_802_11_AUTH_REQUEST_PAIRWISE_ERROR or NDIS_802_11_AUTH_REQUEST_GROUP_ERROR. The driver must also discard the packet data and not make a receive indication.

  • If the device detects another integrity failure within 60 seconds after making the authentication indication, then the driver must make another authentication indication. The driver must follow the same procedure for this indication as described above.

    In addition, the device must disassociate after transmitting the next 802.1X EAPOL packet that results from the authentication indication.

 

 

Send comments about this topic to Microsoft