NDIS_STATUS_PM_WAKE_REASON

NTDEV
1

Hi!

My Win8 NDIS miniport driver supports PM events such as WakeOnMagic/WakeOnPattern. However, it does not advertise support for NDIS_PM_WAKE_PACKET_INDICATION_SUPPORTED. So, can someone please answer these questions?

1… Does the Win8 driver that supports any PM events still need to indicate NDIS_STATUS_PM_WAKE_REASON when resuming to D0 if the NIC asserted PME? The reason I ask is the WDK says the following:

”Starting with NDIS 6.30, miniport drivers can issue an NDIS wake reason status indication (NDIS_STATUS_PM_WAKE_REASON) to notify NDIS and overlying drivers about the reason for a system wake-up event.”

2… If the NDIS_STATUS_PM_WAKE_REASON is required, can the miniport set InfoBufferOffset and InfoBufferSize to 0 in the NDIS_PM_WAKE_REASON structure if it sets WakeReason to NdisWakeReasonPacket? Again, this is for the case where the miniport does not set the NDIS_PM_WAKE_PACKET_INDICATION_SUPPORTED bit in the Flags member of the NDIS_PM_CAPABILITIES struct,

3… As an alternative to #2, should the miniport not issue NDIS_STATUS_PM_WAKE_REASON for WakeReason == NdisWakeReasonPacket if it does not support returning the wakeup packet?
Thanks!

2
  1. If you don’t advertise NDIS_PM_WAKE_PACKET_INDICATION_SUPPORTED, then you don’t *have* to indicate up a NDIS_STATUS_PM_WAKE_REASON. However, there’s still some value in doing so (if you can). The indication can be used to diagnose spurious wakes. There is an event log entry that the administrator can look at.

Of course, if your hardware doesn’t tell you why it woke up, then you obviously can’t make the status indication. The status indication is not required for client/server hardware. (AOAC hardware does require it, I believe.)

  1. It’s ok to set the WakeReason to NdisWakeReasonPacket, but set WakeReason->InfoBufferSize to zero. It’s still useful to know that it was a bitmap pattern that woke us up, even if your hardware is unable to recall the exact packet.

There is, however, a significant advantage to being able to indicate up the first few bytes of the packet along with the status indication: if the wake pattern happened to be a TCP SYN, then the TCP stack will get that SYN+ACK out the door a few hundred milliseconds faster, when the first SYN makes it up through the wake indication. Again, I believe that AOAC-class network hardware has some requirements on how many bytes must be indicated up with the status indication.

  1. It’s best to indicate the wake reason with a zero-byte packet payload.

(Sorry for the long delay in replying… it’s been a busy week here)