Q on NdisReturnPackets

NTDEV
1

From DDK help on NdisReturnPackets:
A ProtocolReceive function cannot begin postprocessing a packet of received
data and forwarding the processed data to clients until the driver’s
ProtocolReceiveComplete function is called.

I am still somewhat new to n/w driver programming on w2k, and the wording
above is not clear: If in my IM driver I do an indication of the packet to
my upperlayer, but fail to do an NdisReturnPackets on the original pkt desc
that was indicated to me by the lower level driver … does it mean that *my
indication* will be on hold as well?

Thanks
-Johnny

Send and receive Hotmail on your mobile device: http://mobile.msn.com

2

“Johnny D” wrote in message news:xxxxx@ntdev…
>
> From DDK help on NdisReturnPackets:
> A ProtocolReceive function cannot begin postprocessing a packet of
received
> data and forwarding the processed data to clients until the driver’s
> ProtocolReceiveComplete function is called.
>

This is correct, of course.

The important thing to understand is that you do not receive NDIS packets
(that is NDIS_PACKETs) in your ProtocolReceive handler. So, you have nothing
to return from your ProtocolReceive handler and you will NEVER call
NdisReturnPackets because of anything passed to you there.

Also understand that there are two(2) functions in your protocol
characteristics that can be used to be given packet information to you from
lower-level:

1.) ProtocolReceive handler (HeaderBuffer.LookaheadBuffer)
2.) ProtocolReceiePacket handler (and arrap of NDIS_PACKETs)

They are very different in their behavior. Don’t confuse them. For example,
ProtocolReceiveComplete is only associated with ProtocolReceive handler; it
is NOT involved when ProtocolReceivePackets is called.

Also, you MUST have a ProtocolReceive handler. A ProtocolReceivePacket
handler is “optional”, but you would be remiss to leave it out (except at
first as you learn…).

> I am still somewhat new to n/w driver programming on w2k, and the wording
> above is not clear: If in my IM driver I do an indication of the packet to
> my upperlayer, but fail to do an NdisReturnPackets on the original pkt
desc
> that was indicated to me by the lower level driver … does it mean that
my
> indication will be on hold as well?
>

Now you are possibly talking about how to handle packets passed to you from
below to an entirely different handler: the ProtocolReceivePackets handler.

The answer to your question depends on how you build the packet that you
pass upwards to the higher level.

If it is entirely your creation (you allocated NDIS_PACKET, NDIS_BUFFER(s),
and virtual memory for packet data), then your indication upwards is
entirely independent from when you call NdisReturnPackets to return the
original packet to the lower level.

If the packet you indicate upwards reference the original packet received
from below (e.g., just "re-wrapped the original), then you cannot call
NdisReturnPackets until your MiniportReturnPacket has been called from
above.

If you examine PassThru you will find this logic somewhere.

Good luck,
–
Thomas F. Divine

PCAUSA - Tools & Resources For Network Software Developers
NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
http: - http:</http:></http:>

3

> 1.) ProtocolReceive handler (HeaderBuffer.LookaheadBuffer)

BTW - can NdisTransferData be called only from ProtocolReceive? Or can the protocol delay NdisTransferData by queuing a DPC or such?

Max

4

> ----------

From: xxxxx@storagecraft.com[SMTP:xxxxx@storagecraft.com]
Reply To: xxxxx@lists.osr.com
Sent: Thursday, April 04, 2002 11:51 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Q on NdisReturnPackets

> 1.) ProtocolReceive handler (HeaderBuffer.LookaheadBuffer)

BTW - can NdisTransferData be called only from ProtocolReceive? Or can the
protocol delay NdisTransferData by queuing a DPC or such?

IMHO yes, it can be called only from ProtocolReceive. There is
MacReceiveContext parameter (which is usually underlying packet descriptor)
which isn’t valid after ProtocolReceive return. It makes sense;
ProtocolReceive is called when a miniport calls NdisMIndicateReceive packet
and sets packet status to NDIS_STATUS_RESOURCES so it wants reuse packet
immediately after its return.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

5

Thanks to all who responded to my earlier questio. Follow up q: When your
ProtocolReceivePacket function returns 0 (for the case where we arent doing
an indication to the above driver), will our ReturnPacket function ever be
called?. If ReceiveIndicate is never called, then all the garbage collection
for the packet should be done by ourself, , right?. Do we also do an
NdisReturnPacket, if not - then how will our lower level driver reclaim its
packets?

Thanks
-Johnny

From: “Maxim S. Shatskih”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Q on NdisReturnPackets
>Date: Fri, 5 Apr 2002 01:51:48 +0400
>
> > 1.) ProtocolReceive handler (HeaderBuffer.LookaheadBuffer)
>
>
>BTW - can NdisTransferData be called only from ProtocolReceive? Or can the
>protocol delay NdisTransferData by queuing a DPC or such?
>
> Max
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

6

When You Pass A Packet Upwards

Your MiniportReturnPacket is only called if 1.) You decide to call
NdisMIndicateReceivePacket to pass one or more packets upwards and 2.)
the higher-level claims the packet by setting OOB Status to
NDIS_STATUS_PENDING. In this case your MiniportReturnPacket handler will
eventually be called to return the packet that you passed upwards to
you.

When You Claim A Packet From Below

If you return 0 from your ProtocolReceivePacket function then you are
through with the packet that came from below.

If you return non-zero, then you have the responsibility to eventually
call NdisReturnPacket to return the packet that you have claimed to its
original owner.

In an NDIS IM driver these functions MIGHT be related. If, for
example, you simply re-wrap a packet that was received on your
ProtocolReceiveHandler and then call NdisMIndicateReceivePacket to pass
the re-wrapped packet upwards THEN when your MiniportReturnPacket
handler is called you will also need to call NdisReturnPacket to return
the original packet to the owner below you.

Hope this helps.

Thomas

-----Original Message-----
From: Johnny D [mailto:xxxxx@hotmail.com]
Sent: Friday, April 05, 2002 3:27 PM
To: xxxxx@lists.osr.com
Cc: xxxxx@hotmail.com
Subject: Re: [ntdev] Re: Q on NdisReturnPackets

Thanks to all who responded to my earlier questio. Follow up q: When
your ProtocolReceivePacket function returns 0 (for the case where we
arent doing an indication to the above driver), will our ReturnPacket
function ever be called?. If ReceiveIndicate is never called, then all
the garbage collection for the packet should be done by ourself, ,
right?. Do we also do an NdisReturnPacket, if not - then how will our
lower level driver reclaim its packets?

Thanks
-Johnny

7

Thomas,
I am a bit confused by your point on IM driver. Anything indicated from
ProtocolReceiveHandler must be copied. If the IM indicates such a copied
packet with NdisMIndicateReceivePacket, then when IM driver’s
MiniportReturnPacket gets called there is no need to call NdisReturnPacket
on the lower miniport because the original packet is indicated through
ProtocolReceiveHandler and it is copied. However, if one uses
NdisGetReceivedPacket to get the received packet and wrap that with a new
packet and indicate that with NdisMIndicateReceivePacket without setting the
packet status to NDIS_STATUS_RESOURCES, then I think your point on IM driver
may apply. I am not sure that this is a validate way of doing that, the idea
is anything from ProtocolReceiveHandler is kind of urgent and one has to set
the new packet with NDIS_STATUS_RESOURCES before indicate up using
NdisMIndicateReceivePacket.

BR!

Jicun Zhong

----- Original Message -----
From: “Thomas F. Divine”
To: “NT Developers Interest List”
Sent: Friday, April 05, 2002 11:57 PM
Subject: [ntdev] Re: Q on NdisReturnPackets

>
> When You Pass A Packet Upwards
> ==============================
> Your MiniportReturnPacket is only called if 1.) You decide to call
> NdisMIndicateReceivePacket to pass one or more packets upwards and 2.)
> the higher-level claims the packet by setting OOB Status to
> NDIS_STATUS_PENDING. In this case your MiniportReturnPacket handler will
> eventually be called to return the packet that you passed upwards to
> you.
>
> When You Claim A Packet From Below
> ==================================
> If you return 0 from your ProtocolReceivePacket function then you are
> through with the packet that came from below.
>
> If you return non-zero, then you have the responsibility to eventually
> call NdisReturnPacket to return the packet that you have claimed to its
> original owner.
>
>
> In an NDIS IM driver these functions MIGHT be related. If, for
> example, you simply re-wrap a packet that was received on your
> ProtocolReceiveHandler and then call NdisMIndicateReceivePacket to pass
> the re-wrapped packet upwards THEN when your MiniportReturnPacket
> handler is called you will also need to call NdisReturnPacket to return
> the original packet to the owner below you.
>
> Hope this helps.
>
> Thomas
>
>
> -----Original Message-----
> From: Johnny D [mailto:xxxxx@hotmail.com]
> Sent: Friday, April 05, 2002 3:27 PM
> To: xxxxx@lists.osr.com
> Cc: xxxxx@hotmail.com
> Subject: Re: [ntdev] Re: Q on NdisReturnPackets
>
>
> Thanks to all who responded to my earlier questio. Follow up q: When
> your ProtocolReceivePacket function returns 0 (for the case where we
> arent doing an indication to the above driver), will our ReturnPacket
> function ever be called?. If ReceiveIndicate is never called, then all
> the garbage collection for the packet should be done by ourself, ,
> right?. Do we also do an NdisReturnPacket, if not - then how will our
> lower level driver reclaim its packets?
>
> Thanks
> -Johnny
>
> —
> You are currently subscribed to ntdev as: xxxxx@vallcom.com
> To unsubscribe send a blank email to %%email.unsub%%
>

8

The original poster was (apparently) totally confused by the fact there are
two different ways to receive packets. In previous posts in this thread I
think that I showed the difference between the two.

The latter message showed (to me) that he has a similar confusion about the
use of NdisReturnPacket, so I answered in a way that I thought HE would get
the most from.

I think the post that you are mentioning is correct as-is.

However, I didn’t add the extra confusion (to him) of discussing the topic
that you brought up.

As you said, if you get a packet at your ProtocolReceiveHandler, then you
must copy the data. There is certainly no reason to call NdisReturnPacket in
this case, (because there is no lower-level packet to return).

If you then call NdisMIndicateReceivePacket with your “cloned” packet, then
the higher-level protocol may call your MiniportReturnPacket to return your
cloned packet (if it claimed it). In your MiniportRetrunPacket you would
only need to free your own resources (your cloned packet) and would NOT need
to call NdisReturnPacket (because there is no lower-level packet to return).

Concerning your suggestion about fetching a pointer to the received packet
using NdisGetReceivedPacket (in ProtocolReceiveHandler), re-wrap that and
pass it upwards using NdisMIndicateReceivePackets:

Very bad idea IMHO.

I believe that the packet pointer fetched with NdisGetReceivedPacket is
read-only an one cannot presume that the pointer fetched this way will exist
after ProtocolReceiveHandler exits. If NdisGetReceivedPacket works (and is
does not always), then one can inspect the receive packet and copy necessary
data - but you can’t re-wrap it.

Good luck,

Thomas F. Divine

PCAUSA - Tools & Resources For Network Software Developers
NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
http: - http:

“Jicun Zhong” wrote in message news:xxxxx@ntdev…
>
> Thomas,
> I am a bit confused by your point on IM driver. Anything indicated
from
> ProtocolReceiveHandler must be copied. If the IM indicates such a copied
> packet with NdisMIndicateReceivePacket, then when IM driver’s
> MiniportReturnPacket gets called there is no need to call NdisReturnPacket
> on the lower miniport because the original packet is indicated through
> ProtocolReceiveHandler and it is copied. However, if one uses
> NdisGetReceivedPacket to get the received packet and wrap that with a new
> packet and indicate that with NdisMIndicateReceivePacket without setting
the
> packet status to NDIS_STATUS_RESOURCES, then I think your point on IM
driver
> may apply. I am not sure that this is a validate way of doing that, the
idea
> is anything from ProtocolReceiveHandler is kind of urgent and one has to
set
> the new packet with NDIS_STATUS_RESOURCES before indicate up using
> NdisMIndicateReceivePacket.
>
> BR!
>
> Jicun Zhong
>
> ----- Original Message -----
> From: “Thomas F. Divine”
> To: “NT Developers Interest List”
> Sent: Friday, April 05, 2002 11:57 PM
> Subject: [ntdev] Re: Q on NdisReturnPackets
>
>
> >
> > When You Pass A Packet Upwards
> > ==============================
> > Your MiniportReturnPacket is only called if 1.) You decide to call
> > NdisMIndicateReceivePacket to pass one or more packets upwards and 2.)
> > the higher-level claims the packet by setting OOB Status to
> > NDIS_STATUS_PENDING. In this case your MiniportReturnPacket handler will
> > eventually be called to return the packet that you passed upwards to
> > you.
> >
> > When You Claim A Packet From Below
> > ==================================
> > If you return 0 from your ProtocolReceivePacket function then you are
> > through with the packet that came from below.
> >
> > If you return non-zero, then you have the responsibility to eventually
> > call NdisReturnPacket to return the packet that you have claimed to its
> > original owner.
> >
> >
> > In an NDIS IM driver these functions MIGHT be related. If, for
> > example, you simply re-wrap a packet that was received on your
> > ProtocolReceiveHandler and then call NdisMIndicateReceivePacket to pass
> > the re-wrapped packet upwards THEN when your MiniportReturnPacket
> > handler is called you will also need to call NdisReturnPacket to return
> > the original packet to the owner below you.
> >
> > Hope this helps.
> >
> > Thomas
> >
> >
> > -----Original Message-----
> > From: Johnny D [mailto:xxxxx@hotmail.com]
> > Sent: Friday, April 05, 2002 3:27 PM
> > To: xxxxx@lists.osr.com
> > Cc: xxxxx@hotmail.com
> > Subject: Re: [ntdev] Re: Q on NdisReturnPackets
> >
> >
> > Thanks to all who responded to my earlier questio. Follow up q: When
> > your ProtocolReceivePacket function returns 0 (for the case where we
> > arent doing an indication to the above driver), will our ReturnPacket
> > function ever be called?. If ReceiveIndicate is never called, then all
> > the garbage collection for the packet should be done by ourself, ,
> > right?. Do we also do an NdisReturnPacket, if not - then how will our
> > lower level driver reclaim its packets?
> >
> > Thanks
> > -Johnny
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@vallcom.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
></http:></http:>

9

As I understand it, the purpose of NdisGetReceivedPacket is to relay the
original packet so that the upper protocols can get the OOB data set at the
bottom of the stack. But I think it is still valide to wrap the returned
packet and indicate up using NdisMIndicateReceivePackets as long as
NDIS_STATUS_RESOURCES is set on the new wrapping packet because that will
force the upper protocol to copy or relay just as the current layer and your
are still not returning from your ProtocolReceiveHandler so the data is
valid. Actually the passthru sample is doing exactly that. This is kind of
optimized operation if the current is layer has nothing to do with the
packet.

BR!

Jicun

----- Original Message -----
From: “Thomas F. Divine”
Newsgroups: ntdev
To: “NT Developers Interest List”
Sent: Saturday, April 06, 2002 5:58 PM
Subject: [ntdev] Re: Q on NdisReturnPackets

> The original poster was (apparently) totally confused by the fact there
are
> two different ways to receive packets. In previous posts in this thread I
> think that I showed the difference between the two.
>
> The latter message showed (to me) that he has a similar confusion about
the
> use of NdisReturnPacket, so I answered in a way that I thought HE would
get
> the most from.
>
> I think the post that you are mentioning is correct as-is.
>
> However, I didn’t add the extra confusion (to him) of discussing the topic
> that you brought up.
>
> As you said, if you get a packet at your ProtocolReceiveHandler, then you
> must copy the data. There is certainly no reason to call NdisReturnPacket
in
> this case, (because there is no lower-level packet to return).
>
> If you then call NdisMIndicateReceivePacket with your “cloned” packet,
then
> the higher-level protocol may call your MiniportReturnPacket to return
your
> cloned packet (if it claimed it). In your MiniportRetrunPacket you would
> only need to free your own resources (your cloned packet) and would NOT
need
> to call NdisReturnPacket (because there is no lower-level packet to
return).
>
> Concerning your suggestion about fetching a pointer to the received packet
> using NdisGetReceivedPacket (in ProtocolReceiveHandler), re-wrap that and
> pass it upwards using NdisMIndicateReceivePackets:
>
> Very bad idea IMHO.
>
> I believe that the packet pointer fetched with NdisGetReceivedPacket is
> read-only an one cannot presume that the pointer fetched this way will
exist
> after ProtocolReceiveHandler exits. If NdisGetReceivedPacket works (and is
> does not always), then one can inspect the receive packet and copy
necessary
> data - but you can’t re-wrap it.
>
> Good luck,
> –
> Thomas F. Divine
>
> PCAUSA - Tools & Resources For Network Software Developers
> NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
> http: - http:
>
> “Jicun Zhong” wrote in message news:xxxxx@ntdev…
> >
> > Thomas,
> > I am a bit confused by your point on IM driver. Anything indicated
> from
> > ProtocolReceiveHandler must be copied. If the IM indicates such a copied
> > packet with NdisMIndicateReceivePacket, then when IM driver’s
> > MiniportReturnPacket gets called there is no need to call
NdisReturnPacket
> > on the lower miniport because the original packet is indicated through
> > ProtocolReceiveHandler and it is copied. However, if one uses
> > NdisGetReceivedPacket to get the received packet and wrap that with a
new
> > packet and indicate that with NdisMIndicateReceivePacket without setting
> the
> > packet status to NDIS_STATUS_RESOURCES, then I think your point on IM
> driver
> > may apply. I am not sure that this is a validate way of doing that, the
> idea
> > is anything from ProtocolReceiveHandler is kind of urgent and one has to
> set
> > the new packet with NDIS_STATUS_RESOURCES before indicate up using
> > NdisMIndicateReceivePacket.
> >
> > BR!
> >
> > Jicun Zhong
> >
> > ----- Original Message -----
> > From: “Thomas F. Divine”
> > To: “NT Developers Interest List”
> > Sent: Friday, April 05, 2002 11:57 PM
> > Subject: [ntdev] Re: Q on NdisReturnPackets
> >
> >
> > >
> > > When You Pass A Packet Upwards
> > > ==============================
> > > Your MiniportReturnPacket is only called if 1.) You decide to call
> > > NdisMIndicateReceivePacket to pass one or more packets upwards and 2.)
> > > the higher-level claims the packet by setting OOB Status to
> > > NDIS_STATUS_PENDING. In this case your MiniportReturnPacket handler
will
> > > eventually be called to return the packet that you passed upwards to
> > > you.
> > >
> > > When You Claim A Packet From Below
> > > ==================================
> > > If you return 0 from your ProtocolReceivePacket function then you are
> > > through with the packet that came from below.
> > >
> > > If you return non-zero, then you have the responsibility to eventually
> > > call NdisReturnPacket to return the packet that you have claimed to
its
> > > original owner.
> > >
> > >
> > > In an NDIS IM driver these functions MIGHT be related. If, for
> > > example, you simply re-wrap a packet that was received on your
> > > ProtocolReceiveHandler and then call NdisMIndicateReceivePacket to
pass
> > > the re-wrapped packet upwards THEN when your MiniportReturnPacket
> > > handler is called you will also need to call NdisReturnPacket to
return
> > > the original packet to the owner below you.
> > >
> > > Hope this helps.
> > >
> > > Thomas
> > >
> > >
> > > -----Original Message-----
> > > From: Johnny D [mailto:xxxxx@hotmail.com]
> > > Sent: Friday, April 05, 2002 3:27 PM
> > > To: xxxxx@lists.osr.com
> > > Cc: xxxxx@hotmail.com
> > > Subject: Re: [ntdev] Re: Q on NdisReturnPackets
> > >
> > >
> > > Thanks to all who responded to my earlier questio. Follow up q: When
> > > your ProtocolReceivePacket function returns 0 (for the case where we
> > > arent doing an indication to the above driver), will our ReturnPacket
> > > function ever be called?. If ReceiveIndicate is never called, then all
> > > the garbage collection for the packet should be done by ourself, ,
> > > right?. Do we also do an NdisReturnPacket, if not - then how will our
> > > lower level driver reclaim its packets?
> > >
> > > Thanks
> > > -Johnny
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@vallcom.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@vallcom.com
> To unsubscribe send a blank email to %%email.unsub%%
></http:></http:>

10

Yes, PassThru does that. The key is that it calls NdisMIndicateReceive from
within the ProtocolReceive handler. So, for all practical purposes my
comment applies:

The pointer fetched using NdisGetReceivePacket is valid only until
ProtocolReceive exits.

Don’t let a novice believe that the packet fetched with NdisGetReceivePacket
can be queued for examination or deferred indication outside the scope of
the ProtocolReceive handler. It’ll be gonzo (or well could be…).

Thos

“Jicun Zhong” wrote in message news:xxxxx@ntdev…
>
> As I understand it, the purpose of NdisGetReceivedPacket is to relay the
> original packet so that the upper protocols can get the OOB data set at
the
> bottom of the stack. But I think it is still valide to wrap the returned
> packet and indicate up using NdisMIndicateReceivePackets as long as
> NDIS_STATUS_RESOURCES is set on the new wrapping packet because that will
> force the upper protocol to copy or relay just as the current layer and
your
> are still not returning from your ProtocolReceiveHandler so the data is
> valid. Actually the passthru sample is doing exactly that. This is kind of
> optimized operation if the current is layer has nothing to do with the
> packet.
>
> BR!
>

11

Thanks to all who replied. I am now clearer on the path(s) that can be
taken by packets in an IM driver. I have one other question: I perform some
packet manipulations in my driver and then send the packet above to the IP
layer. How can I be sure that my indication succeeded. “netstat -s” by
itself didnt show that the packet got dropped. Basically if I need to set
breakpoints in the IP receive function for the NT code, can I do it. Where
can I get the symbols and info for the same? . Are there other ways to find
out the same?

-Johnny

From: “Thomas F. Divine”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Q on NdisReturnPackets
>Date: Sat, 6 Apr 2002 14:01:09 -0500
>
>Yes, PassThru does that. The key is that it calls NdisMIndicateReceive from
>within the ProtocolReceive handler. So, for all practical purposes my
>comment applies:
>
> The pointer fetched using NdisGetReceivePacket is valid only until
>ProtocolReceive exits.
>
>Don’t let a novice believe that the packet fetched with
>NdisGetReceivePacket
>can be queued for examination or deferred indication outside the scope of
>the ProtocolReceive handler. It’ll be gonzo (or well could be…).
>
>Thos
>
>“Jicun Zhong” wrote in message news:xxxxx@ntdev…
> >
> > As I understand it, the purpose of NdisGetReceivedPacket is to relay the
> > original packet so that the upper protocols can get the OOB data set at
>the
> > bottom of the stack. But I think it is still valide to wrap the returned
> > packet and indicate up using NdisMIndicateReceivePackets as long as
> > NDIS_STATUS_RESOURCES is set on the new wrapping packet because that
>will
> > force the upper protocol to copy or relay just as the current layer and
>your
> > are still not returning from your ProtocolReceiveHandler so the data is
> > valid. Actually the passthru sample is doing exactly that. This is kind
>of
> > optimized operation if the current is layer has nothing to do with the
> > packet.
> >
> > BR!
> >
>
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

12

> itself didnt show that the packet got dropped. Basically if I need to set

breakpoints in the IP receive function for the NT code, can I do it. Where
can I get the symbols and info for the same?

Symbols are on MSDN’s Customer Support Diagnostic CD or together with the Service Pack.
Set the breakpoint to IPRcv or ARPRcv.

Max

13

I am using the symbols from http://msdl.microsoft.com/download/symbols and I didnt find IPRcv as an exported symbol in tcpip.sys . Does the CD have more symbols than what they put up on site?

Thanks

-Johnny

====

Here’s the complete list that I have:


0: kd> x tcpip!*



f1cae340 tcpip!IPTransmit



f1cb078b tcpip!IPGetAddrType



f1cb62c8 tcpip!tcpxsum



f1ccfe00 tcpip!IPInjectPkt



f1cd0495 tcpip!IPFreeBuff



f1cd04c1 tcpip!FreeIprBuff



f1cd04dc tcpip!IPAllocBuff



f1cd0ec0 tcpip!LookupRoute



f1cd0eed tcpip!LookupRouteInformation



f1cd0f0c tcpip!LookupRouteInformationWithBuffer



f1cd3b17 tcpip!GetIFAndLink



f1cd3c37 tcpip!SetIPSecPtr



f1cd3ca5 tcpip!UnSetIPSecPtr



f1cd3d19 tcpip!UnSetIPSecSendPtr



f1cd410c tcpip!IPDelayedNdisReEnumerateBindings



f1cd4197 tcpip!IPRegisterARP



f1cd4289 tcpip!IPDeregisterARP



f1cd448a tcpip!IPRegisterProtocol



f1cd4bc5 tcpip!IPGetInfo



f1cd61be tcpip!IPAddInterface



f1cd7463 tcpip!IPGetBestInterface



f1cd7552 tcpip!IPDelInterface



f1cd7cd9 tcpip!IPProxyNdisRequest



f1cd7d4c tcpip!IPEnableSniffer



f1cd7ec8 tcpip!IPDisableSniffer



f1cd7fee tcpip!IPSetIPSecStatus



f1cdbe56 tcpip!SendICMPErr

 

From: “Maxim S. Shatskih”

>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Q on NdisReturnPackets
>Date: Mon, 8 Apr 2002 19:01:31 +0400
>
> > itself didnt show that the packet got dropped. Basically if I need to set
> > breakpoints in the IP receive function for the NT code, can I do it. Where
> > can I get the symbols and info for the same?
>
>Symbols are on MSDN’s Customer Support Diagnostic CD or together with the Service Pack.
>Set the breakpoint to IPRcv or ARPRcv.
>
> Max
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

Send and receive Hotmail on your mobile device: Click Here

14

There is yet another problem with NdisGetReceivedPacket(). It doesn’t return
the packet packet which below layered driver indicated which is documented
in the DDK but returns packet set using NDIS_SET_ORIGINAL_PACKET macro
instead. So passthru code

NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(Packet));

is wrong if MyPacket contains modified packet buffers. The problem is
unfortunately invisible until passthru-like filter is layered above
modifying driver (mentioned optimization chains buffers before modification
to packet descriptor). The workaround is to clear original packet field in
MyPacket or set it to MyPacket.

It is unclear if there is a bug in the docs or implementation of
NdisGetReceivedPacket. My guess is implementation.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: xxxxx@lists.osr.com
Sent: Saturday, April 06, 2002 9:01 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Q on NdisReturnPackets

Yes, PassThru does that. The key is that it calls NdisMIndicateReceive
from
within the ProtocolReceive handler. So, for all practical purposes my
comment applies:

The pointer fetched using NdisGetReceivePacket is valid only until
ProtocolReceive exits.

Don’t let a novice believe that the packet fetched with
NdisGetReceivePacket
can be queued for examination or deferred indication outside the scope of
the ProtocolReceive handler. It’ll be gonzo (or well could be…).

Thos

“Jicun Zhong” wrote in message news:xxxxx@ntdev…
> >
> > As I understand it, the purpose of NdisGetReceivedPacket is to relay the
> > original packet so that the upper protocols can get the OOB data set at
> the
> > bottom of the stack. But I think it is still valide to wrap the returned
> > packet and indicate up using NdisMIndicateReceivePackets as long as
> > NDIS_STATUS_RESOURCES is set on the new wrapping packet because that
> will
> > force the upper protocol to copy or relay just as the current layer and
> your
> > are still not returning from your ProtocolReceiveHandler so the data is
> > valid. Actually the passthru sample is doing exactly that. This is kind
> of
> > optimized operation if the current is layer has nothing to do with the
> > packet.
> >
> > BR!
> >
>
>
>
>
> —
> You are currently subscribed to ntdev as: michal.vodicka@st.com
> To unsubscribe send a blank email to %%email.unsub%%
>

15

Michal,
What does NdisGetReceivedPacket returns the packet set by
NDIS_SET_ORIGINAL_PACKET to do with packet buffer modification? That song
really strange. What I understand is NdisGetReceivedPacket is geting a
packet saved somewhere in the MINIPORT_BLOCK that has nothing to do with the
original packet field in the packet extenstion. How did you find out what
you said?

Jicun

----- Original Message -----
From: “Michal Vodicka”
To: “NT Developers Interest List”
Sent: Monday, April 08, 2002 8:24 PM
Subject: [ntdev] Re: Q on NdisReturnPackets

> There is yet another problem with NdisGetReceivedPacket(). It doesn’t
return
> the packet packet which below layered driver indicated which is documented
> in the DDK but returns packet set using NDIS_SET_ORIGINAL_PACKET macro
> instead. So passthru code
>
> NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(Packet));
>
> is wrong if MyPacket contains modified packet buffers. The problem is
> unfortunately invisible until passthru-like filter is layered above
> modifying driver (mentioned optimization chains buffers before
modification
> to packet descriptor). The workaround is to clear original packet field in
> MyPacket or set it to MyPacket.
>
> It is unclear if there is a bug in the docs or implementation of
> NdisGetReceivedPacket. My guess is implementation.
>
> Best regards,
>
> Michal Vodicka
> STMicroelectronics Design and Application s.r.o.
> [michal.vodicka@st.com, http:://www.st.com]
>
> > ----------
> > From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Saturday, April 06, 2002 9:01 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: Q on NdisReturnPackets
> >
> > Yes, PassThru does that. The key is that it calls NdisMIndicateReceive
> > from
> > within the ProtocolReceive handler. So, for all practical purposes my
> > comment applies:
> >
> > The pointer fetched using NdisGetReceivePacket is valid only until
> > ProtocolReceive exits.
> >
> > Don’t let a novice believe that the packet fetched with
> > NdisGetReceivePacket
> > can be queued for examination or deferred indication outside the scope
of
> > the ProtocolReceive handler. It’ll be gonzo (or well could be…).
> >
> > Thos
> >
> > “Jicun Zhong” wrote in message news:xxxxx@ntdev…
> > >
> > > As I understand it, the purpose of NdisGetReceivedPacket is to relay
the
> > > original packet so that the upper protocols can get the OOB data set
at
> > the
> > > bottom of the stack. But I think it is still valide to wrap the
returned
> > > packet and indicate up using NdisMIndicateReceivePackets as long as
> > > NDIS_STATUS_RESOURCES is set on the new wrapping packet because that
> > will
> > > force the upper protocol to copy or relay just as the current layer
and
> > your
> > > are still not returning from your ProtocolReceiveHandler so the data
is
> > > valid. Actually the passthru sample is doing exactly that. This is
kind
> > of
> > > optimized operation if the current is layer has nothing to do with the
> > > packet.
> > >
> > > BR!
> > >
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: michal.vodicka@st.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@vallcom.com
> To unsubscribe send a blank email to %%email.unsub%%
>

16

It is not exported - it is internal, in debug info only.

Max

----- Original Message -----
From: Johnny D
To: NT Developers Interest List
Sent: Monday, April 08, 2002 10:24 PM
Subject: [ntdev] Re: Q on NdisReturnPackets

I am using the symbols from http://msdl.microsoft.com/download/symbols and I didnt find IPRcv as an exported symbol in tcpip.sys . Does the CD have more symbols than what they put up on site?

Thanks

-Johnny

====

Here’s the complete list that I have:

0: kd> x tcpip!*

f1cae340 tcpip!IPTransmit

f1cb078b tcpip!IPGetAddrType

f1cb62c8 tcpip!tcpxsum

f1ccfe00 tcpip!IPInjectPkt

f1cd0495 tcpip!IPFreeBuff

f1cd04c1 tcpip!FreeIprBuff

f1cd04dc tcpip!IPAllocBuff

f1cd0ec0 tcpip!LookupRoute

f1cd0eed tcpip!LookupRouteInformation

f1cd0f0c tcpip!LookupRouteInformationWithBuffer

f1cd3b17 tcpip!GetIFAndLink

f1cd3c37 tcpip!SetIPSecPtr

f1cd3ca5 tcpip!UnSetIPSecPtr

f1cd3d19 tcpip!UnSetIPSecSendPtr

f1cd410c tcpip!IPDelayedNdisReEnumerateBindings

f1cd4197 tcpip!IPRegisterARP

f1cd4289 tcpip!IPDeregisterARP

f1cd448a tcpip!IPRegisterProtocol

f1cd4bc5 tcpip!IPGetInfo

f1cd61be tcpip!IPAddInterface

f1cd7463 tcpip!IPGetBestInterface

f1cd7552 tcpip!IPDelInterface

f1cd7cd9 tcpip!IPProxyNdisRequest

f1cd7d4c tcpip!IPEnableSniffer

f1cd7ec8 tcpip!IPDisableSniffer

f1cd7fee tcpip!IPSetIPSecStatus

f1cdbe56 tcpip!SendICMPErr

From: “Maxim S. Shatskih”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Q on NdisReturnPackets
>Date: Mon, 8 Apr 2002 19:01:31 +0400
>
> > itself didnt show that the packet got dropped. Basically if I need to set
> > breakpoints in the IP receive function for the NT code, can I do it. Where
> > can I get the symbols and info for the same?
>
>Symbols are on MSDN’s Customer Support Diagnostic CD or together with the Service Pack.
>Set the breakpoint to IPRcv or ARPRcv.
>
> Max
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

Send and receive Hotmail on your mobile device: Click Here

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%

17

Thanks Maxim for your answers. Does this mean that I will have to install a debug/checked build, and then the special debug symbols for the same. The problem is that with MSDN i only have a CD for Win2k professional debug/checked build, *not server* as I would have surely preferred. Is there a way to get around this?

Regards

-Johnny

It is not exported - it is internal, in debug info only.

 

Max

 

From: “Maxim S. Shatskih”

>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Q on NdisReturnPackets
>Date: Mon, 8 Apr 2002 19:01:31 +0400
>
> > itself didnt show that the packet got dropped. Basically if I need to set
> > breakpoints in the IP receive function for the NT code, can I do it. Where
> > can I get the symbols and info for the same?
>
>Symbols are on MSDN’s Customer Support Diagnostic CD or together with the Service Pack.
>Set the breakpoint to IPRcv or ARPRcv.
>
> Max
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

MSN Photos is the easiest way to share and print your photos: Click Here

18

> ----------

From: xxxxx@vallcom.com[SMTP:xxxxx@vallcom.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, April 08, 2002 10:09 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Q on NdisReturnPackets

Michal,
What does NdisGetReceivedPacket returns the packet set by
NDIS_SET_ORIGINAL_PACKET to do with packet buffer modification? That song
really strange.

Jicun, imagine you have encryption packet filter. Its ProtocolReceive
handler allocates new packet descriptor and attaches decrypted packet
buffers. It calls NdisGetReceivedPacket() and copies all necessary info
including original packet field to its descriptor (as passthru suggests).
Then sets packet status to NDIS_STATUS_RESOURCES and calls
NdisMIndicateReceive packet.

Now imagine there is passthru-like driver layered above. ProtocolReceive
handler calls NdisGetReceivePacket() which returns original *encrypted*
packet descriptor and re-attaches its buffers to new descriptor exactly as
passthru does. It indicates packet and above protocol receives encrypted
packet which can’t deal with.

What I understand is NdisGetReceivedPacket is geting a
packet saved somewhere in the MINIPORT_BLOCK that has nothing to do with
the
original packet field in the packet extenstion.

It should but doesn’t. That’s my point. It gets packet saved in
MINIPORT_BLOCK and returns original packet field saved in its extension.

How did you find out what
you said?

My encryption driver failed when QOS packet scheduler (which reattaches
buffers the same way as passthru) was layered above. So I took debugger and
found the problem. I verified it last time for w2k SP2 but after quick look
to XP code I believe problem is still present.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

Jicun

----- Original Message -----
From: “Michal Vodicka”
> To: “NT Developers Interest List”
> Sent: Monday, April 08, 2002 8:24 PM
> Subject: [ntdev] Re: Q on NdisReturnPackets
>
>
> > There is yet another problem with NdisGetReceivedPacket(). It doesn’t
> return
> > the packet packet which below layered driver indicated which is
> documented
> > in the DDK but returns packet set using NDIS_SET_ORIGINAL_PACKET macro
> > instead. So passthru code
> >
> > NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(Packet));
> >
> > is wrong if MyPacket contains modified packet buffers. The problem is
> > unfortunately invisible until passthru-like filter is layered above
> > modifying driver (mentioned optimization chains buffers before
> modification
> > to packet descriptor). The workaround is to clear original packet field
> in
> > MyPacket or set it to MyPacket.
> >
> > It is unclear if there is a bug in the docs or implementation of
> > NdisGetReceivedPacket. My guess is implementation.
> >
> > Best regards,
> >
> > Michal Vodicka
> > STMicroelectronics Design and Application s.r.o.
> > [michal.vodicka@st.com, http:://www.st.com]
> >
>

19

> ----------

From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: xxxxx@lists.osr.com
Sent: Monday, April 08, 2002 10:48 PM
To: xxxxx@lists.osr.com
Cc: xxxxx@storagecraft.com
Subject: [ntdev] Re: Q on NdisReturnPackets

Thanks Maxim for your answers. Does this mean that I will have to install
a debug/checked build, and then the special debug symbols for the same.
The problem is that with MSDN i only have a CD for Win2k professional
debug/checked build, *not server* as I would have surely preferred. Is
there a way to get around this?

No. What you need is retail symbols. Simply install them from the CD and
read you favorite debugger docs how to deal with them. Note ws and server
binaries are identical and also symbols.

Best regards,

Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]

20

No, you do not need checked build to find IPRcv.
Load TCPIP symbols to WinDbg and execute:

x tcpip!*

then

x tcpip!IPRcv

Max

----- Original Message -----
From: Johnny D
To: NT Developers Interest List
Cc: xxxxx@storagecraft.com
Sent: Tuesday, April 09, 2002 12:48 AM
Subject: [ntdev] Re: Q on NdisReturnPackets

Thanks Maxim for your answers. Does this mean that I will have to install a debug/checked build, and then the special debug symbols for the same. The problem is that with MSDN i only have a CD for Win2k professional debug/checked build, *not server* as I would have surely preferred. Is there a way to get around this?

Regards

-Johnny

It is not exported - it is internal, in debug info only.

Max

From: “Maxim S. Shatskih”
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: Q on NdisReturnPackets
>Date: Mon, 8 Apr 2002 19:01:31 +0400
>
> > itself didnt show that the packet got dropped. Basically if I need to set
> > breakpoints in the IP receive function for the NT code, can I do it. Where
> > can I get the symbols and info for the same?
>
>Symbols are on MSDN’s Customer Support Diagnostic CD or together with the Service Pack.
>Set the breakpoint to IPRcv or ARPRcv.
>
> Max
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

MSN Photos is the easiest way to share and print your photos: Click Here

You are currently subscribed to ntdev as: xxxxx@storagecraft.com
To unsubscribe send a blank email to %%email.unsub%%