NDIS IM drop packet

NTDEV
1

Hi All.

I have an IM based on passthru. I need to drop delayed packet in receive
handler.

I delay packet by returning NDIS_STATUS_PENDING. Then I’d like to drop it
later. How to do this?

Thanx in advance.

2

Read the DDK documentation for ProtocolReceivePacket. Pay attention to use
of NdisReturnPackets.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com

“Dmitriy Gubarkov” wrote in message news:xxxxx@ntdev…
> Hi All.
>
> I have an IM based on passthru. I need to drop delayed packet in receive
> handler.
>
> I delay packet by returning NDIS_STATUS_PENDING. Then I’d like to drop it
> later. How to do this?
>
> Thanx in advance.
>
>

3

Dmitriy,

I am a bit confused by your statement

>I delay packet by returning NDIS_STATUS_PENDING.

When applied to the ‘receive handler’ of an IM driver since:

  1. The MiniportReceive() handler is not allowed to return
    NDIS_STATUS_PENDING and doing so does not make any sense.
    NDIS_STATUS_PENDING is only used when a transfer of ownership occurs across
    a binding. MiniportReceive() is an ‘indication’ that a packet is available
    and *not* the transfer of ownership of the packet. A protocol must either
    accept or reject the receive, possibly calling NdisTransferData().
    NdisTransferData() *does* pass ownership of the packet from the protocol to
    the MAC and *may* return NDIS_STATUS_PENDING to the protocol. If it does,
    the MAC required to complete the transfer resulting in a
    ProtocolTransferDataComplete() which transfer ownership of the packet back
    to the protocol. At this point the packet resulting from the
    MiniportRecieve() belongs to the protocol (IM driver) and can be ‘dropped’
    simply by choosing not to forward it ‘up’ through the IM miniport. The
    packet is dropped by simply ‘free-ing’ it. For this case, the packet was
    allocated by the protocol (IM) and has been returned to it by the MAC.
    Freeing the buffers and packet are all that is required to drop it.

  2. The MiniportReceivePacket() handler returns a ‘reference count’ and not
    a status. The reference count is the number of times that
    NdisReturnPackets() will be called. Most of the time (and especially if you
    are queueing the packet internally to the IM driver) the return value will
    simply be ‘1’ (one). To drop the packet, again, just don’t forward it
    through the IM upper miniport but *do* ‘free’ the packet by returning it via
    NdisReturnPackets(). In effect, all packets transferred from a MAC to a
    Protocol via ProtocolReceivePacket() are implicitly asyncronous if the
    return value is greater than one. If you return NDIS_STATUS_PENDING from
    this call, you will be telling NDIS that you promise to call
    NdisReturnPackets 259 times (NDIS_STATUS_PENDING is 0x103 or 259). Don’t
    laugh, I have seen this bug before.

The only ‘data path’ on which it is reasonable to return the status of
NDIS_STATUS_PENDING is from MiniportSend(). Indirectly a miniport may set a
packet status to NDIS_STATUS_PENDING in MiniportSendPackets() as well to
indicate that the packet will be completed with a call to
NdisMSendComplete().

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Gubarkov
Sent: Thursday, June 08, 2006 1:34 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] NDIS IM drop packet

Hi All.

I have an IM based on passthru. I need to drop delayed packet in receive
handler.

I delay packet by returning NDIS_STATUS_PENDING. Then I’d like to drop it
later. How to do this?

Thanx in advance.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

Thanx a lot David and Thomas for detailed information. Basically I’ve read
somewhere in this list that packet can be delayed in this way I do it.

“David R. Cattley” ???/??? ? ??? ???:
news:xxxxx@ntdev…
> Dmitriy,
>
> I am a bit confused by your statement
>
>>>I delay packet by returning NDIS_STATUS_PENDING.
>
> When applied to the ‘receive handler’ of an IM driver since:
>
> 1. The MiniportReceive() handler is not allowed to return
> NDIS_STATUS_PENDING and doing so does not make any sense.
> NDIS_STATUS_PENDING is only used when a transfer of ownership occurs
> across
> a binding. MiniportReceive() is an ‘indication’ that a packet is
> available
> and not the transfer of ownership of the packet. A protocol must either
> accept or reject the receive, possibly calling NdisTransferData().
> NdisTransferData() does pass ownership of the packet from the protocol
> to
> the MAC and may return NDIS_STATUS_PENDING to the protocol. If it does,
> the MAC required to complete the transfer resulting in a
> ProtocolTransferDataComplete() which transfer ownership of the packet back
> to the protocol. At this point the packet resulting from the
> MiniportRecieve() belongs to the protocol (IM driver) and can be ‘dropped’
> simply by choosing not to forward it ‘up’ through the IM miniport. The
> packet is dropped by simply ‘free-ing’ it. For this case, the packet was
> allocated by the protocol (IM) and has been returned to it by the MAC.
> Freeing the buffers and packet are all that is required to drop it.
>
> 2. The MiniportReceivePacket() handler returns a ‘reference count’ and
> not
> a status. The reference count is the number of times that
> NdisReturnPackets() will be called. Most of the time (and especially if
> you
> are queueing the packet internally to the IM driver) the return value will
> simply be ‘1’ (one). To drop the packet, again, just don’t forward it
> through the IM upper miniport but do ‘free’ the packet by returning it
> via
> NdisReturnPackets(). In effect, all packets transferred from a MAC to a
> Protocol via ProtocolReceivePacket() are implicitly asyncronous if the
> return value is greater than one. If you return NDIS_STATUS_PENDING from
> this call, you will be telling NDIS that you promise to call
> NdisReturnPackets 259 times (NDIS_STATUS_PENDING is 0x103 or 259). Don’t
> laugh, I have seen this bug before.
>
> The only ‘data path’ on which it is reasonable to return the status of
> NDIS_STATUS_PENDING is from MiniportSend(). Indirectly a miniport may set
> a
> packet status to NDIS_STATUS_PENDING in MiniportSendPackets() as well to
> indicate that the packet will be completed with a call to
> NdisMSendComplete().
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Dmitriy Gubarkov
> Sent: Thursday, June 08, 2006 1:34 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] NDIS IM drop packet
>
> Hi All.
>
> I have an IM based on passthru. I need to drop delayed packet in receive
> handler.
>
> I delay packet by returning NDIS_STATUS_PENDING. Then I’d like to drop it
> later. How to do this?
>
> Thanx in advance.
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>