NDIS ignoring indicated packets

Hello,

Is there a way to tell if NDIS (or the protocol driver upstairs)
rejected or ignored the packets my miniport indicates. For instance, is
it possible to get some status or something when the packet is returned
by NDIS via the returnPackets handler?

I have been doing some reading up on this and it seems like there is a
lot of interesting stuff I have to do before I indicate a packet.

  1. What happens if my packet size (total) is less than what I indicated
    when I was queried about OID_GEN_CURRENT_LOOKAHEAD and
    MAXIMUM_LOOKAHEAD?
  2. When I allocate a buffer using NdisAllocateBuffer, what happens if I
    use the current packet size as the last parameter in the call (size to
    be mapped)? Does this have to be the LookAhead size?
  3. I always set my status to NDIS_STATUS_SUCCESS before indicating it to
    NDIS with the hope that I will cleanup when the packet is returned to me
    later. Is this okay?

Ravi Murty (503) 712 4477
LTG, Communication Architecture Lab
Mobility Group
Intel, Oregon

NDIS ignoring indicated packets
“Murty, Ravi” wrote in message news:xxxxx@ntdev…
Hello,

Is there a way to tell if NDIS (or the protocol driver upstairs) rejected or ignored the packets my miniport indicates. For instance, is it possible to get some status or something when the packet is returned by NDIS via the returnPackets handler?

No, sorry. There is no meaningful feedback to you.

I have been doing some reading up on this and it seems like there is a lot of interesting stuff I have to do before I indicate a packet.

1. What happens if my packet size (total) is less than what I indicated when I was queried about OID_GEN_CURRENT_LOOKAHEAD and MAXIMUM_LOOKAHEAD?

Nothing is wrong in this case. If your packet size is greater than the OID_802_11_CURRENT_LOOKAHEAD

2. When I allocate a buffer using NdisAllocateBuffer, what happens if I use the current packet size as the last parameter in the call (size to be mapped)? Does this have to be the LookAhead size?

HeaderBufferSize plus PacketSize is fine.

Remember that:

1.) A “NDIS packet” (at least 802.3) consists of an Ethernet header (12 bytes) plus the Ethernet payload.

2.) When you indicate a NDIS packet the combined length of the NDIS buffer(s) chained to the packet must be the length of the Ethernet header plus the length of the Ethernet payload.

If you allocate a single NDIS buffer its length must be the sum of the length of the Ethernet header plus the length of the Ethernet payload.

If (for some reason) you decide to use multiple buffers in your indication then there is a quirk (a bug, now assimilated as part of the specification). The first NDIS buffer in an indicated packet must include the Ethernet header plus at least the smaller of a.) the Ethernet payload or b.) OID_GEN_CURRENT_LOOKAHEAD.

3.) In the ProtocolReceive handler the “packet size” is actually the length of the Ethernet payload. It doesn’t include the Ethernet header.

4.) OID_GEN_MAXIMUM_FRAME_SIZE is related only to the maximum size of the Ethernet payload. It does not include the Ethernet header.

5.) OID_GEN_MAXIMUM_TOTAL_SIZE is a value that specifies the maximum total size including the Ethernet header plus the Ethernet payload.

3. I always set my status to NDIS_STATUS_SUCCESS before indicating it to NDIS with the hope that I will cleanup when the packet is returned to me later. Is this okay?

The only value that is meaningful when you make an indication is NDIS_STATUS_RESOURCES.

Hope this helps.

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

____________________________

Ravi Murty (503) 712 4477

LTG, Communication Architecture Lab

Mobility Group

Intel, Oregon

Thomas,

Didn’t realize that the only thing I can setup is NDIS_STATUS_RESOURCES
based on what I found in the DDK documentation.

A deserialized miniport driver must not examine the Status of indicated
packets on return of NdisMIndicateReceivePacket. Instead, a deserialized
miniport driver must save a packet’s Status in a local variable before
indicating up the packet descriptor. When NdisMIndicateReceivePacket
returns, the miniport driver should check the saved packet Status. If
the miniport driver set the packet’s Status to NDIS_STATUS_RESOURCES
before indicating up the packet descriptor, it should reclaim the packet
descriptor immediately after NdisMIndicateReceivePacket returns,
preferably by calling its own MiniportReturnPacket function. In this
case, NDIS does not call the miniport driver’s MiniportReturnPacket
function to return the packet descriptor. If the miniport driver set the
packet’s Status to NDIS_STATUS_SUCCESS before indicating up the packet
descriptor, the miniport driver must not reclaim the packet descriptor
until NDIS subsequently returns the packet descriptor to the miniport
driver’s MiniportReturnPacket function.

Is this true?

thanks

ravi


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, April 20, 2005 11:31 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS ignoring indicated packets

“Murty, Ravi” wrote in message
news:xxxxx@ntdev…

Hello,

Is there a way to tell if NDIS (or the protocol driver upstairs)
rejected or ignored the packets my miniport indicates. For instance, is
it possible to get some status or something when the packet is returned
by NDIS via the returnPackets handler?

No, sorry. There is no meaningful feedback to you.

I have been doing some reading up on this and it seems like
there is a lot of interesting stuff I have to do before I indicate a
packet.

1. What happens if my packet size (total) is less than what I
indicated when I was queried about OID_GEN_CURRENT_LOOKAHEAD and
MAXIMUM_LOOKAHEAD?

Nothing is wrong in this case. If your packet size is greater than the
OID_802_11_CURRENT_LOOKAHEAD

2. When I allocate a buffer using NdisAllocateBuffer, what
happens if I use the current packet size as the last parameter in the
call (size to be mapped)? Does this have to be the LookAhead size?

HeaderBufferSize plus PacketSize is fine.

Remember that:

1.) A “NDIS packet” (at least 802.3) consists of an Ethernet header (12
bytes) plus the Ethernet payload.

2.) When you indicate a NDIS packet the combined length of the NDIS
buffer(s) chained to the packet must be the length of the Ethernet
header plus the length of the Ethernet payload.

If you allocate a single NDIS buffer its length must be the sum of the
length of the Ethernet header plus the length of the Ethernet payload.

If (for some reason) you decide to use multiple buffers in your
indication then there is a quirk (a bug, now assimilated as part of the
specification). The first NDIS buffer in an indicated packet must
include the Ethernet header plus at least the smaller of a.) the
Ethernet payload or b.) OID_GEN_CURRENT_LOOKAHEAD.

3.) In the ProtocolReceive handler the “packet size” is actually the
length of the Ethernet payload. It doesn’t include the Ethernet header.

4.) OID_GEN_MAXIMUM_FRAME_SIZE is related only to the maximum size of
the Ethernet payload. It does not include the Ethernet header.

5.) OID_GEN_MAXIMUM_TOTAL_SIZE is a value that specifies the maximum
total size including the Ethernet header plus the Ethernet payload.

3. I always set my status to NDIS_STATUS_SUCCESS before
indicating it to NDIS with the hope that I will cleanup when the packet
is returned to me later. Is this okay?

The only value that is meaningful when you make an indication is
NDIS_STATUS_RESOURCES.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.ndis.com

____________________________

Ravi Murty (503) 712 4477

LTG, Communication Architecture Lab

Mobility Group

Intel, Oregon


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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

NDIS ignoring indicated packets
“Murty, Ravi” wrote in message news:xxxxx@ntdev…
Thomas,

Didn’t realize that the only thing I can setup is NDIS_STATUS_RESOURCES based on what I found in the DDK documentation.

A deserialized miniport driver must not examine the Status of indicated packets on return of NdisMIndicateReceivePacket. Instead, a deserialized miniport driver must save a packet’s Status in a local variable before indicating up the packet descriptor. When NdisMIndicateReceivePacket returns, the miniport driver should check the saved packet Status. If the miniport driver set the packet’s Status to NDIS_STATUS_RESOURCES before indicating up the packet descriptor, it should reclaim the packet descriptor immediately after NdisMIndicateReceivePacket returns, preferably by calling its own MiniportReturnPacket function. In this case, NDIS does not call the miniport driver’s MiniportReturnPacket function to return the packet descriptor. If the miniport driver set the packet’s Status to NDIS_STATUS_SUCCESS before indicating up the packet descriptor, the miniport driver must not reclaim the packet descriptor until NDIS subsequently returns the packet descriptor to the miniport driver’s MiniportReturnPacket function.

Is this true?

The DDK statement si true, of course. I over-simplified. Sorry.

Hope the other info was useful.

Thomas F. Divine, Windows DDK MVP

http://www.rawether.net

thanks

ravi

------------------------------------------------------------------------------

From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, April 20, 2005 11:31 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS ignoring indicated packets

“Murty, Ravi” wrote in message news:xxxxx@ntdev…

Hello,

Is there a way to tell if NDIS (or the protocol driver upstairs) rejected or ignored the packets my miniport indicates. For instance, is it possible to get some status or something when the packet is returned by NDIS via the returnPackets handler?

No, sorry. There is no meaningful feedback to you.

I have been doing some reading up on this and it seems like there is a lot of interesting stuff I have to do before I indicate a packet.

1. What happens if my packet size (total) is less than what I indicated when I was queried about OID_GEN_CURRENT_LOOKAHEAD and MAXIMUM_LOOKAHEAD?

Nothing is wrong in this case. If your packet size is greater than the OID_802_11_CURRENT_LOOKAHEAD

2. When I allocate a buffer using NdisAllocateBuffer, what happens if I use the current packet size as the last parameter in the call (size to be mapped)? Does this have to be the LookAhead size?

HeaderBufferSize plus PacketSize is fine.

Remember that:

1.) A “NDIS packet” (at least 802.3) consists of an Ethernet header (12 bytes) plus the Ethernet payload.

2.) When you indicate a NDIS packet the combined length of the NDIS buffer(s) chained to the packet must be the length of the Ethernet header plus the length of the Ethernet payload.

If you allocate a single NDIS buffer its length must be the sum of the length of the Ethernet header plus the length of the Ethernet payload.

If (for some reason) you decide to use multiple buffers in your indication then there is a quirk (a bug, now assimilated as part of the specification). The first NDIS buffer in an indicated packet must include the Ethernet header plus at least the smaller of a.) the Ethernet payload or b.) OID_GEN_CURRENT_LOOKAHEAD.

3.) In the ProtocolReceive handler the “packet size” is actually the length of the Ethernet payload. It doesn’t include the Ethernet header.

4.) OID_GEN_MAXIMUM_FRAME_SIZE is related only to the maximum size of the Ethernet payload. It does not include the Ethernet header.

5.) OID_GEN_MAXIMUM_TOTAL_SIZE is a value that specifies the maximum total size including the Ethernet header plus the Ethernet payload.

3. I always set my status to NDIS_STATUS_SUCCESS before indicating it to NDIS with the hope that I will cleanup when the packet is returned to me later. Is this okay?

The only value that is meaningful when you make an indication is NDIS_STATUS_RESOURCES.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.ndis.com

____________________________

Ravi Murty (503) 712 4477

LTG, Communication Architecture Lab

Mobility Group

Intel, Oregon


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

You are currently subscribed to ntdev as: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

Thanks for the clarification Thomas, and yes the rest of the stuff is
very helpful.

Ravi


From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, April 20, 2005 1:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS ignoring indicated packets

“Murty, Ravi” wrote in message
news:xxxxx@ntdev…

Thomas,

Didn’t realize that the only thing I can setup is
NDIS_STATUS_RESOURCES based on what I found in the DDK documentation.

A deserialized miniport driver must not examine the Status of
indicated packets on return of NdisMIndicateReceivePacket. Instead, a
deserialized miniport driver must save a packet’s Status in a local
variable before indicating up the packet descriptor. When
NdisMIndicateReceivePacket returns, the miniport driver should check the
saved packet Status. If the miniport driver set the packet’s Status to
NDIS_STATUS_RESOURCES before indicating up the packet descriptor, it
should reclaim the packet descriptor immediately after
NdisMIndicateReceivePacket returns, preferably by calling its own
MiniportReturnPacket function. In this case, NDIS does not call the
miniport driver’s MiniportReturnPacket function to return the packet
descriptor. If the miniport driver set the packet’s Status to
NDIS_STATUS_SUCCESS before indicating up the packet descriptor, the
miniport driver must not reclaim the packet descriptor until NDIS
subsequently returns the packet descriptor to the miniport driver’s
MiniportReturnPacket function.

Is this true?

The DDK statement si true, of course. I over-simplified. Sorry.

Hope the other info was useful.

Thomas F. Divine, Windows DDK MVP

http://www.rawether.net

thanks

ravi

________________________________

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Wednesday, April 20, 2005 11:31 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] NDIS ignoring indicated packets

“Murty, Ravi” wrote in message
news:xxxxx@ntdev…

Hello,

Is there a way to tell if NDIS (or the protocol driver
upstairs) rejected or ignored the packets my miniport indicates. For
instance, is it possible to get some status or something when the packet
is returned by NDIS via the returnPackets handler?

No, sorry. There is no meaningful feedback to you.

I have been doing some reading up on this and it seems
like there is a lot of interesting stuff I have to do before I indicate
a packet.

1. What happens if my packet size (total) is less than
what I indicated when I was queried about OID_GEN_CURRENT_LOOKAHEAD and
MAXIMUM_LOOKAHEAD?

Nothing is wrong in this case. If your packet size is greater
than the OID_802_11_CURRENT_LOOKAHEAD

2. When I allocate a buffer using NdisAllocateBuffer,
what happens if I use the current packet size as the last parameter in
the call (size to be mapped)? Does this have to be the LookAhead size?

HeaderBufferSize plus PacketSize is fine.

Remember that:

1.) A “NDIS packet” (at least 802.3) consists of an Ethernet
header (12 bytes) plus the Ethernet payload.

2.) When you indicate a NDIS packet the combined length of the
NDIS buffer(s) chained to the packet must be the length of the Ethernet
header plus the length of the Ethernet payload.

If you allocate a single NDIS buffer its length must be the sum
of the length of the Ethernet header plus the length of the Ethernet
payload.

If (for some reason) you decide to use multiple buffers in your
indication then there is a quirk (a bug, now assimilated as part of the
specification). The first NDIS buffer in an indicated packet must
include the Ethernet header plus at least the smaller of a.) the
Ethernet payload or b.) OID_GEN_CURRENT_LOOKAHEAD.

3.) In the ProtocolReceive handler the “packet size” is actually
the length of the Ethernet payload. It doesn’t include the Ethernet
header.

4.) OID_GEN_MAXIMUM_FRAME_SIZE is related only to the maximum
size of the Ethernet payload. It does not include the Ethernet header.

5.) OID_GEN_MAXIMUM_TOTAL_SIZE is a value that specifies the
maximum total size including the Ethernet header plus the Ethernet
payload.

3. I always set my status to NDIS_STATUS_SUCCESS before
indicating it to NDIS with the hope that I will cleanup when the packet
is returned to me later. Is this okay?

The only value that is meaningful when you make an indication is
NDIS_STATUS_RESOURCES.

Hope this helps.

Thomas F. Divine, Windows DDK MVP

http://www.ndis.com

____________________________

Ravi Murty (503) 712 4477

LTG, Communication Architecture Lab

Mobility Group

Intel, Oregon


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

You are currently subscribed to ntdev as: unknown lmsubst tag
argument: ‘’
To unsubscribe send a blank email to
xxxxx@lists.osr.com


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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com