canceling oid request in NDIS driver

Question

How to cancel oid request. Can anybody please tell me detailed procedure? Suppose NDIS sends any request to miniport driver. How driver will cancel the request and send it to the miniport driver.

Answer 1

There is some information on OID handling here. Each OID has a cancellation ID in NDIS_OID_REQEST::RequestId. If NDIS wants to cancel an OID request, NDIS will call into your miniport's MiniportCancelOidRequest handler, passing a RequestId. Your miniport should compare the RequestId to the request ID of the current OID request. If the RequestId matches, your miniport should expedite the completion of the OID request, since the higher layers no longer need the operation to complete.

However, your miniport driver is not obligated to cancel any request, and in particular, you should not waste time attempting to "undo" a request. NDIS knows that the cancellation may come "too late", and NDIS is prepared to issue additional OIDs to correctly roll back the operation, if needed.

So for a miniport, these are all valid ways to handle a cancellation request:

1. Ignore the cancellation, and continue processing the request anyway. Complete the request with NDIS_STATUS_SUCCESS (or a failure code, if the operation failed).
2. Attempt to cancel the operation (e.g., by calling IoCancelIrp or similar).
   • If the operation was actually cancelled (e.g., your IRP's completion handler got STATUS_CANCELLED), then return NDIS_STATUS_REQUEST_ABORTED.
   • If the operation succeeded anyway (e.g., your IRP's completion handler got STATUS_SUCCESS), then return NDIS_STATUS_SUCCESS, even though you attempted to cancel.

For the "trivial" OIDs, don't bother implementing cancellation. For example, if you can satisfy OID_GEN_STATISTICS without going to hardware just by copying data into the OID's buffer, then don't bother trying to implement cancellation for this OID. Cancellation would just add a bunch of overhead without being truly useful.

Cancellation is more useful when an OID request results in a blocking call to hardware (e.g., sending an URB down to a USB gadget).

Make sure that, if an OID requires multiple calls, and you cancel after the first call, you restore the hardware to a known state. For example, if handling OID_PNP_SET_POWER requires you to make 10 calls to hardware, and you decide to implement cancellation for this OID, you should safely restore hardware to its previous power state if the OID is cancelled after the 3rd hardware call.