Gee, I don't know. How about you didn't pass a valid PNDIS_PACKET pointer
to it?
Do you have a debugger? Use it. We are not clairvoyant mind readers here.
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Subashini
Venkatapathy ,Chennai
Sent: Saturday, September 19, 2009 11:03 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] reg. call to ProtocolReceive and ProtocolReceivePacket
function
I tried calling NDIS_GET_PACKET_STATUS in my ProtocolReceive function and my
system crashed. What might be the possible reason for this?
Thank you all for providing me so much information.
With Regards,
Subashini
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Saturday, September 19, 2009 7:34 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] reg. call to ProtocolReceive and ProtocolReceivePacket
function
And what value is returned by NDIS_GET_PACKET_STATUS() for the packet
returned by NdisGetReceivePacket()? Is it NDIS_STATUS_RESOURCES?
Well no matter.
Whenever NDIS provides a packet via NdisGetReceivePacket() it is to be
treated *as if* it has NDIS_STATUS_RESOURCES set in its status. You cannot
actually test the value and treat it otherwise. It just so happens that in
the case of a IM driver exclusively bound to the NIC that in this case, it
probably does have NDIS_STATUS_RESOURCES set - just a diagnostic peek into
what is going on.
None the less, this is an entirely 'normal' state of affairs for an IM
driver. You need to test on more NICs.
From your original post:
According to my understanding it should enter into ProtocolReceive routine
only when
there is less resource available? Please correct me if I am wrong.
No, that is not true. This thread lists multiple reasons.
- NDIS decides to do so because the packet has already been indicated to
another binding and cannot be indicated to two bindings.
- NDIS decides to because the packet is indicated with
NDIS_STATUS_RESOURCES
- NDIS decides to because the packet is being looped-back.
- The NIC indicated with legacy media specific receive instead of receive
packet.
- The Protocol did not register a receive packet handler.
Also could you please tell me what might be the possible reason for this and
is
there any thing I should set or do to enter into ProtocolReceivePacket
function?
See above. In your particular case, go by yourself some other NICs. I
don't mean to say that the RTL8139 is bad in any way but I can tell you that
you have now tested on *one* NIC and that one (and depending on driver
version) has some rather peculiar behaviors. Good for you. Now go get some
systems with some other NICs - recent hardware from Broadcom, Intel, etc.
If you are serious about making sure your IM driver is working correctly,
you had best test on a large variety of NICs, version of MAC drivers, and
O/S platforms.
Regarding the RTL8139 - I have this vague recollection that its drivers
recently went from always using legacy receives to using packet indications.
I know I keep a few of these devices in the testing lab just because the
older drivers did the legacy receive and it was getting harder & harder to
reliably test an IM or protocol drivers handling of that case (where it
really had to do NdisTransferData() calls). My recollection is that when it
changed to using packet indications, each indication was with
NDIS_STATUS_RESOURCES because nothing actually changed in the way the NIC
works - there was still just one receive buffer or some such. Again, I
don't know. I didn't write the driver. I could be (and probably am)
completely wrong about the RTL8139. I just know that the RTL8139 has been
a real treasure for helping to find bugs in IM drivers 
Good Luck,
Dave Cattley
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Subashini
Venkatapathy ,Chennai
Sent: Saturday, September 19, 2009 7:51 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] reg. call to ProtocolReceive and ProtocolReceivePacket
function
Hello,
I am using Realtek RTL8139 Family PCI Fast Ethernet NIC and working on
filter IM driver.
I am sure that I am getting a packet because when I check for Packet != NULL
after calling NdisGetReceivePacket, the condition becomes true.
Thanks & Regards,
Subashini
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of David R. Cattley
Sent: Friday, September 18, 2009 10:02 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] reg. call to ProtocolReceive and ProtocolReceivePacket
function
What is the underlying NIC card you are working with? Some rather popular
(aka, cheap) NICs still work this way.
Post a stack back-trace of a call to your ProtocolReceive.
You said you are an IM driver - does that mean 'filter' driver with an
exclusive binding at the Protocol edge to the underlying NIC? If so, except
for loopback, you should get a ProtocolReceivePacket whenever the NIC
indicates with the 'PACKET' style receive (and not the legacy receive).
While it is true what Thomas said about NDIS calling across multiple
bindings where only the first binding gets the 'packet' and all other get
the legacy indication, this would not generally apply to a IM Filter driver
since it is the 'only' protocol bound to the NIC (typically).
More than likely the NIC just does not do packet indications
(NdisMIndicateReceivePacket) but uses media specific receive indications.
Next most likely is that you did something wrong when registering the
protocol.
A stack back-trace will answer that question because it will be obvious is
NDIS got the packet originally from a media specific indication.
Another equally valid way of knowing this is if NdisGetReceivePacket()
returns a packet or not. If it does not, then, well, there never was a
packet.
Good Luck,
Dave Cattley
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Thomas F. Divine
Sent: Friday, September 18, 2009 11:52 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] reg. call to ProtocolReceive and ProtocolReceivePacket
function
Unfortunately you have no control over this. Which routine NDIS may call is
determined by its internal logic.
NDIS may very well call TCP/IP at its ProtocolReceivePacket handler and
"concurrently" call your IMs protocol handler at ProtocolReceive. This gives
and advantage to the Microsoft protocol - since it provides the system's IP
support.
Even so I do see calls to the NDIS 5 IM driver's ProtocolReceivePacket
handler much of the time (just checked with debugger...). If you have
registered both handler's then I can't explain why your
ProtocolReceivepacket ould never be called.
Good luck,
Thomas F. Divine
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Subashini
Venkatapathy ,Chennai
Sent: Friday, September 18, 2009 11:28 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] reg. call to ProtocolReceive and ProtocolReceivePacket
function
Hello,
I am developing an NDIS IM driver. When I receive a message it always enters
into my ProtocolReceive routine rather than ProtocolReceivePacket. According
to my understanding it should enter into ProtocolReceive routine only when
there is less resource available? Please correct me if I am wrong. Also
could you please tell me what might be the possible reason for this and is
there any thing I should set or do to enter into ProtocolReceivePacket
function?
I have registered both ProtocolReceive and ProtocolReceivePacket in my
DriverEntry function.
I am working on NDIS 5.1. Any help would be highly appreciated. Thanks!
With Regards,
Subashini
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at
ListServer/Forum
DISCLAIMER:
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its
affiliates. Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect
the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail
is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
To unsubscribe, visit the List Server section of OSR Online at