No return of NDIS5.1 NdisMIndicateReceivePacket()

OSR_Community_User · March 20, 2008, 1:47am

Hi all,

My NDIS5.1 IM driver gets the TCP packet from its ProtocolReceive function registered at (ndisPChars.ReceiveHandler). After it prepares its own packet with the received packet content, re-calculates the IP and TCP checksums and uses NdisAdjustBufferLength() to resize its own packet accordingly, it passes its own packet to the upper TCP/IP protocol driver, using the NDIS5.1 NdisMIndicateReceivePacket() call. Unfortunately, this NdisMIndicateReceivePacket() call does not return. From my driver’s point of view, that packet is lost, dropped by the ProtocolReceive function of that protocol driver.

I visited the http://www.osronline.com/custom.cfm?pr=ntdev&searchString=ndismindicatereceivepacket+never+return&pageURL=http%3A%2F%2Fwww.osronline.com%2Fscripts%2Ftexis.exe%2Fwebinator%2Fsearch%2F&name=index_fullframeset.cfm&cmd=&imageField.x=13&imageField.y=13 http: website. I discovered that this problem happens to other five NDIS5.1 driver developers but there is no single solution to them.

I will be definitely grateful to receive from you a solid and confirmed solution to this problem. If you need any more information about my problem I will be more than happy to provide. Meanwhile I will look into the ProtocolReceive function in the NDIS5.1 passthru sample driver to find out the reasons for dropping the received packet. If I can figure out the solution, I will share it with you.

Tommy

________________________________

From: Lyris ListManager [mailto:xxxxx@lists.osr.com]
Sent: Thu 3/20/2008 2:07 AM
To: Tommy Lee
Subject: Welcome to the NTDEV Discussion List!

Welcome to the NTDEV Discussion List!

Please read this message completely. It includes info on how to
access the list as well as a list of appropriate behaviors.

This is the Windows System Software Development discussion list, with a
world-wide membership. To send messages to the mailing list use the
address:

xxxxx@lists.osr.com

Your message will automatically be distributed to all members of
the list. Only list members can post to the list. The means that
the address from which you post must be the address you subscribe
to the list with.

PURPOSE
This list is maintained by OSR Open Systems Resources, Inc. for the
overall benefit of the Windows system software development community.
The purpose of this list is to facilitate discussion of technical
topics relating to Windows system software development.

Most questions about using/accessing the list are answered by the
List FAQ. You can find this at:

http://www.osronline.com/page.cfm?name=ListServerFAQ

We suggest that you go read it now.

BEHAVIOR
The following are specifically inappropriate regarding this list:

1) Commercial postings - This is a technical list, and the only
posts that are allowed are technical in nature. Please don’t post
advertisements or announcements for your products, services, or
activities to the list. Your posting will NOT be considered
technical(and thus legitimate), just because it starts with “I just
wanted all you to know that we’ve released a new version of” some
software. On the other hand, if somebody posts question saying
“Can anybody recommend a good XYZ?”, it’s perfectly fine to answer
“Yeah, we make XYZ’s and we think they’re pretty cool. Please
contact me off-list for more info.”

2) Job solicitations - Not from commercial concerns looking for
developers, not from head hunters, not from small companies, not
from people looking for work, not from consultants looking for
clients. There is a Windows drivers job posting bulletin board
for both people seeking jobs and people who are looking for
developers at http://www.osronline.com http:</http:> . Use it, not this list.

3) Salary, consulting rate or price discussions - Something about
the laws here in the States about price fixing comes into play here.
Please just don’t do it.

4) Use of the email addresses of list members for “direct mail
advertising” of any type.

5) Anything that, in the judgment of the list managers, is not in
keeping with the overall purpose of the list or is not in the best
interest of the Windows system software development community.

Multiple incidents of inappropriate conduct on the list will result
in that member, and perhaps all members from the offender’s company,
being banned from the list.

There are a number of other items that are seriously discouraged,
and tend to annoy the List Slaves (those who administer the lists).
For example, PLEASE DO NOT POST THE SAME QUESTION TO BOTH NTDEV and
NTFSD. Also, please do the list members the courtesy of searching
the archives before you post a question.

READING, POSTING, SEARCHING
You may read messages from, and post messages to, this list in either of
three ways:

1) Via email (discussion, digest, or index). Select the type via
the web interface (see “Managing Your List Membership” below).

2) Via a news reader (such as outlook express). Point your
newsreader to lists.osr.com, use your email address as your
username and supply the password that you used when you signed up.

A complete description of how to participate in the list, including
a detailed description of how to set-up and use the Outlook Newsreader
with NTDEV is available at http://www.osronline.com/page.cfm?name=ListServer

The list archive is maintained on the web, in full text searchable
form. The search facility is available from the homepage at
http://www.osronline.com http:</http:> (select NTDEV from the drop-down menu in
the SEARCH box on the left).

Postings to this list should be in plain ASCII text (postings in
HTML are presently allowed, but not greatly appreciated by the list
members). Postings with attachments (or multiple body parts) will be
rejected.

MANAGING YOUR LIST MEMBERSHIP
Almost everything that you might ever need to do regarding your list
membership is most easily and effectively performed via Lyris’s Web
interface at http://www.osronline.com/page.cfm?name=ListServer.
Go check it out now…

The web interface allows you to select which TYPE of membership
(discussion, digest, index, no mail), allows you to manage your
list password (which can be different from your OSR Online password),
and allows you to re-set your account when it has been put on “hold”.

Every message you receive has a footer that tells you how to get off
this list. Please, we beg you, Do NOT send administrative requests
to the posting address “xxxxx@lists.osr.com”.

If you have ANY problems related to the ntdev Discussion List,
please do not post them to the list. List managers (A.K.A. List
Slaves) are at your disposal for this very purpose; please avail
yourself of the resource:

xxxxx@lists.osr.com

The List Slaves do not monitor the list every day. Mostly, the list
just runs itself. If you experience problems with the list, or you
stop getting postings from the list for several days, please don’t
hesitate to contact the List Slaves.

Once again, welcome to the NTDEV Discussion List.

The List Team
OSR Open Systems Resources, Inc.</http:>

anton_bassov · March 20, 2008, 2:49am

> Unfortunately, this NdisMIndicateReceivePacket() call does not return.

I just wonder how something like that may possibly happen…
What happens to execution floww then???

From my driver’s point of view, that packet is lost, dropped by the ProtocolReceive
function of that protocol driver.

Bound protocols just cannot “drop” a packet. If you set NDIS_STATUS_RESOURCES in a packet, bound protocols are forced to make their own copies of it, so that you can free it immediately after NdisMIndicateReceivePacket() returns control. Otherwise, packet gets returned to your MiniportReturn() when all bound protocols that returned non-zero refcount from their ProtocolReceivePacket () call NdisReturnPacket(), so that its refcount goes to zero.

Anton Bassov

David_R_Cattley · March 20, 2008, 7:52am

Please clarify what you mean by

Unfortunately, this NdisMIndicateReceivePacket() call does not return

Is it:

The function call does not return. (Very unlikely - is your CPU
still hung?)
The packet indicated is not returned via your
MiniportReturnPacket() entry. (More likely).

If what you mean is (2) then ensure that you have set the NDIS_PACKET status
to NDIS_STATUS_SUCCESS prior to indicating the packet with
NdisMIndicateReceivePacket().

I discovered that this problem happens to other five NDIS5.1 driver
developers but there is no single solution to them.

I tried to find what you meant by this by looking at the search URL
reference you provided. I could not determine which of the *many* threads
that were returned you are referring to. I can assure you that there
is no hidden problem with IM drivers and indicating receive packets here.

There are many problems with developers not understanding the myriad rules
of NDIS and not getting the details correct and thus causing problems. In
this case (miniport packet indication) the rules (a small relevant subset)
are thus:

A miniport that indicates a packet via NdisMIndicateRecievePacket()
must set the packet status with NDIS_SET_PACKET_STATUS() to either
NDIS_STATUS_SUCCESS or NDIS_STATUS_RESOURCES prior to indicating the packet.
Technically, the value that changes behavior is NDIS_STATUS_RESOURCES. Any
other value should not change behavior. However, using the rule of “be
conservative in what you do and liberal in what you expect” it is best to
set the value to NDIS_STATUS_SUCCESS or NDIS_STATUS_RESOURCES but only
*test* the value for NDIS_STATUS_RESOURCES. Other drivers bound above you
might not tolerate other values.
A miniport that indicates a packet with packet status set to a
value *not* equal to NDIS_STATUS_RESOURCES *will* be called at the
MiniportReturnPacket() with the indicated packet when the packet is no
longer referenced by any bound protocol. The miniport *must not* access the
packet during this time.
A miniport that indicates a packet with packet status set to a
value of NDIS_STATUS_RESOURCES *will not* be called at the
MiniportReturnPacket() entry with this packet. The miniport is guaranteed
that when NdisMIndicateReceivePackets() returns, the packet is not
referenced by any bound protocols.
Any packet indicated by a miniport must have the header length set
to the actual MAC header length with NDIS_SET_PACKET_HEADER_SIZE().
Any packet indicated by a miniport must contain the minimum
look-a-head data (or the entire packet if smaller) in the first NDIS_BUFFER
as set by OID_GEN_CURRENT_LOOKAHEAD. NOTE: This is especially important
for IM drivers that modify or create IP packets. The MAC header and IP
header must be in the first NDIS_BUFFER otherwise TCPIP.SYS will ignore the
packet. There are both clever and brute-force techniques for dealing with
this.

I suspect that in your case you may be copying the packet status from the
original packet to the copy your driver has made and this packet status
might be NDIS_STATUS_RESOURCES. This case *is* handled correctly by
PASSTHRU so please go review that your driver is likewise handling it
correctly.

Good Luck,

Dave Cattley

Consulting Engineer

Systems Software Development

From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tommy Lee
Sent: Thursday, March 20, 2008 1:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] No return of NDIS5.1 NdisMIndicateReceivePacket()

Hi all,

My NDIS5.1 IM driver gets the TCP packet from its ProtocolReceive function
registered at (ndisPChars.ReceiveHandler). After it prepares its own packet
with the received packet content, re-calculates the IP and TCP checksums and
uses NdisAdjustBufferLength() to resize its own packet accordingly, it
passes its own packet to the upper TCP/IP protocol driver, using the NDIS5.1
NdisMIndicateReceivePacket() call. Unfortunately, this
NdisMIndicateReceivePacket() call does not return. From my driver’s point of
view, that packet is lost, dropped by the ProtocolReceive function of that
protocol driver.

I visited the
http:ivepacket+never+return&pageURL=http%3A%2F%2Fwww.osronline.com%2Fscripts%2Fte
xis.exe%2Fwebinator%2Fsearch%2F&name=index_fullframeset.cfm&cmd=&imageField.
x=13&imageField.y=13>
http://www.osronline.com/custom.cfm?pr=ntdev&searchString=ndismindicaterecei
vepacket+never+return&pageURL=http%3A%2F%2Fwww.osronline.com%2Fscripts%2Ftex
is.exe%2Fwebinator%2Fsearch%2F&name=index_fullframeset.cfm&cmd=&imageField.x
=13&imageField.y=13 website. I discovered that this problem happens to other
five NDIS5.1 driver developers but there is no single solution to them.

I will be definitely grateful to receive from you a solid and confirmed
solution to this problem. If you need any more information about my problem
I will be more than happy to provide. Meanwhile I will look into the
ProtocolReceive function in the NDIS5.1 passthru sample driver to find out
the reasons for dropping the received packet. If I can figure out the
solution, I will share it with you.

Tommy

_____

From: Lyris ListManager [mailto:xxxxx@lists.osr.com]
Sent: Thu 3/20/2008 2:07 AM
To: Tommy Lee
Subject: Welcome to the NTDEV Discussion List!

Welcome to the NTDEV Discussion List!

Please read this message completely. It includes info on how to
access the list as well as a list of appropriate behaviors.

This is the Windows System Software Development discussion list, with a
world-wide membership. To send messages to the mailing list use the
address:

xxxxx@lists.osr.com

Your message will automatically be distributed to all members of
the list. Only list members can post to the list. The means that
the address from which you post must be the address you subscribe
to the list with.

PURPOSE
This list is maintained by OSR Open Systems Resources, Inc. for the
overall benefit of the Windows system software development community.
The purpose of this list is to facilitate discussion of technical
topics relating to Windows system software development.

Most questions about using/accessing the list are answered by the
List FAQ. You can find this at:

http://www.osronline.com/page.cfm?name=ListServerFAQ

We suggest that you go read it now.

BEHAVIOR
The following are specifically inappropriate regarding this list:

1) Commercial postings - This is a technical list, and the only
posts that are allowed are technical in nature. Please don’t post
advertisements or announcements for your products, services, or
activities to the list. Your posting will NOT be considered
technical(and thus legitimate), just because it starts with “I just
wanted all you to know that we’ve released a new version of” some
software. On the other hand, if somebody posts question saying
“Can anybody recommend a good XYZ?”, it’s perfectly fine to answer
“Yeah, we make XYZ’s and we think they’re pretty cool. Please
contact me off-list for more info.”

2) Job solicitations - Not from commercial concerns looking for
developers, not from head hunters, not from small companies, not
from people looking for work, not from consultants looking for
clients. There is a Windows drivers job posting bulletin board
for both people seeking jobs and people who are looking for
developers at http://www.osronline.com http:</http:> . Use
it, not this list.

3) Salary, consulting rate or price discussions - Something about
the laws here in the States about price fixing comes into play here.
Please just don’t do it.

4) Use of the email addresses of list members for “direct mail
advertising” of any type.

5) Anything that, in the judgment of the list managers, is not in
keeping with the overall purpose of the list or is not in the best
interest of the Windows system software development community.

Multiple incidents of inappropriate conduct on the list will result
in that member, and perhaps all members from the offender’s company,
being banned from the list.

There are a number of other items that are seriously discouraged,
and tend to annoy the List Slaves (those who administer the lists).
For example, PLEASE DO NOT POST THE SAME QUESTION TO BOTH NTDEV and
NTFSD. Also, please do the list members the courtesy of searching
the archives before you post a question.

READING, POSTING, SEARCHING
You may read messages from, and post messages to, this list in either of
three ways:

1) Via email (discussion, digest, or index). Select the type via
the web interface (see “Managing Your List Membership” below).

2) Via a news reader (such as outlook express). Point your
newsreader to lists.osr.com, use your email address as your
username and supply the password that you used when you signed up.

A complete description of how to participate in the list, including
a detailed description of how to set-up and use the Outlook Newsreader
with NTDEV is available at http://www.osronline.com/page.cfm?name=ListServer

The list archive is maintained on the web, in full text searchable
form. The search facility is available from the homepage at
http://www.osronline.com http:</http:> (select NTDEV from the
drop-down menu in
the SEARCH box on the left).

Postings to this list should be in plain ASCII text (postings in
HTML are presently allowed, but not greatly appreciated by the list
members). Postings with attachments (or multiple body parts) will be
rejected.

MANAGING YOUR LIST MEMBERSHIP
Almost everything that you might ever need to do regarding your list
membership is most easily and effectively performed via Lyris’s Web
interface at http://www.osronline.com/page.cfm?name=ListServer.
Go check it out now…

The web interface allows you to select which TYPE of membership
(discussion, digest, index, no mail), allows you to manage your
list password (which can be different from your OSR Online password),
and allows you to re-set your account when it has been put on “hold”.

Every message you receive has a footer that tells you how to get off
this list. Please, we beg you, Do NOT send administrative requests
to the posting address “xxxxx@lists.osr.com”.

If you have ANY problems related to the ntdev Discussion List,
please do not post them to the list. List managers (A.K.A. List
Slaves) are at your disposal for this very purpose; please avail
yourself of the resource:

xxxxx@lists.osr.com

The List Slaves do not monitor the list every day. Mostly, the list
just runs itself. If you experience problems with the list, or you
stop getting postings from the list for several days, please don’t
hesitate to contact the List Slaves.

Once again, welcome to the NTDEV Discussion List.

The List Team
OSR Open Systems Resources, Inc.

—
NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

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