packet indication failing - analysis help reqd.

NTDEV
1

I receive a packet in myReceivePacket() and then I create own descriptor and chain up my own buffers to it and do an NdisMIndicateReceivePacket to the upperlayer. Before passing the pkt up I make sure I have all the right information and all the expected buffers of expected lengths are chained up. Also, for the desciptor that I create I do

NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket)); 

 

I see that my breakpoint for IPRcv is not being hit. Does anyone know what the problem could be ? . How can I set breakpoints to see what happened to the indication … which driver got it… Also since its a deserialized driver, I cant check the status of the pkt after the indicate call, but I set the pkt desc status to NDIS_STATUS_RESOURCES before the indication.

 

Thanks

-Johnny

====----

>From: Michal Vodicka


>Reply-To: “NT Developers Interest List”

>To: “NT Developers Interest List”

>Subject: [ntdev] Re: Q on NdisReturnPackets

>Date: Mon, 8 Apr 2002 23:38:01 +0200

>

> > ----------

> > 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]

> > >

> >

>

>—

>You are currently subscribed to ntdev as: xxxxx@hotmail.com

>To unsubscribe send a blank email to %%email.unsub%%

Chat with friends online, try MSN Messenger: Click Here

Chat with friends online, try MSN Messenger: Click Here

2

What about the breakpoint on ARPRcv? Is it hit?
Try to trace NdisMIndicateReceivePacket step by step.

Max

----- Original Message -----
From: Johnny D
To: NT Developers Interest List
Cc: michal.vodicka@st.com
Sent: Tuesday, April 09, 2002 11:59 PM
Subject: [ntdev] packet indication failing - analysis help reqd.

I receive a packet in myReceivePacket() and then I create own descriptor and chain up my own buffers to it and do an NdisMIndicateReceivePacket to the upperlayer. Before passing the pkt up I make sure I have all the right information and all the expected buffers of expected lengths are chained up. Also, for the desciptor that I create I do

NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket));

I see that my breakpoint for IPRcv is not being hit. Does anyone know what the problem could be ? . How can I set breakpoints to see what happened to the indication … which driver got it… Also since its a deserialized driver, I cant check the status of the pkt after the indicate call, but I set the pkt desc status to NDIS_STATUS_RESOURCES before the indication.

Thanks
-Johnny

====----

>From: Michal Vodicka

>Reply-To: “NT Developers Interest List”
>
>To: “NT Developers Interest List”
>
>Subject: [ntdev] Re: Q on NdisReturnPackets
>
>Date: Mon, 8 Apr 2002 23:38:01 +0200
>
>
>
> > ----------
>
> > 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]
>
> > >
>
> >
>
>
>
>—
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>
>To unsubscribe send a blank email to %%email.unsub%%
>

Chat with friends online, try MSN Messenger: Click Here

Chat with friends online, try MSN Messenger: Click Here

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

3

TCP/IP probably uses TDI Events for receive. This means that the receive event handler - not the receive handler - would be called. These are not static entry points that you can break on just using a debugger and symbol table.

There may be something missing in the OOB data that you haven’t initialized. For example, examine the NDIS queries that pass through your NDIS IM driver for NDIS Task Offload. If the NIC you are using advertises Rx checksum offload support and your home-brew packet doesn’t initialize OOB data correctly, the packet may simply be ignored. Unfortunately, the DDK doesn’t give an example of how an “active” NDIS IM (does something more then PassThru) must deal with this.

If the NDIS miniport and TCP/IP do setup NDIS task offload, you might just try filtering the OID requesting NDIS task offload capabilities; fail the task offload query in your IM and don’t pass it on to the lower-level miniport. If your driver then works in this simplified environment you at least know where you should look. (Don’t bother doing this if you don’t see NDIS TaskOffload being setup. Too much trouble…)

There may be other reasons, and getting it right takes study and experimentation. It took a while to get PCAUSA’s simple “CryptoPing” to work.

Good luck,

Thomas F. Divine

PCAUSA - Tools & Resources For Network Software Developers
NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
http: - http:
“Johnny D” wrote in message news:xxxxx@ntdev…
I receive a packet in myReceivePacket() and then I create own descriptor and chain up my own buffers to it and do an NdisMIndicateReceivePacket to the upperlayer. Before passing the pkt up I make sure I have all the right information and all the expected buffers of expected lengths are chained up. Also, for the desciptor that I create I do

NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket));

I see that my breakpoint for IPRcv is not being hit. Does anyone know what the problem could be ? . How can I set breakpoints to see what happened to the indication … which driver got it… Also since its a deserialized driver, I cant check the status of the pkt after the indicate call, but I set the pkt desc status to NDIS_STATUS_RESOURCES before the indication.

Thanks
-Johnny

====----

>
>From: Michal Vodicka

>
>Reply-To: “NT Developers Interest List”
>
>To: “NT Developers Interest List”
>
>Subject: [ntdev] Re: Q on NdisReturnPackets
>
>Date: Mon, 8 Apr 2002 23:38:01 +0200
>
>
>
> > ----------
>
> > 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]
>
> > >
>
> >
>
>
>
>—
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>
>To unsubscribe send a blank email to %%email.unsub%%
>

------------------------------------------------------------------------------
Chat with friends online, try MSN Messenger: Click Here

>

------------------------------------------------------------------------------
Chat with friends online, try MSN Messenger: Click Here</http:></http:>

4

As per Michals recommendation I am setting the Orignal packet to itself. But before I do this am I still supposed to set the new packet descriptor’s Head and Tail to the passed in packets’ Head and Tail. I bascically will be attaching my own buffers to this new descr, so I believe, unless its affecting the call to the NDIS_SET_ORIGINAL_PACKET macro in some way, I dont need this.

I am still not fully clear on the usage of the OOB data and how its affecting my packet indication. I have been able to pick up bits and pieces from helpful people like Thomas, Michal and Max. As i understand OOB data is as follows:

typedef struct _NDIS_PACKET_OOB_DATA {
union {
ULONGLONG TimeToSend;
ULONGLONG TimeSent;
};
ULONGLONG TimeReceived;
UINT HeaderSize;
UINT SizeMediaSpecificInfo;
PVOID MediaSpecificInformation;
NDIS_STATUS Status;
} NDIS_PACKET_OOB_DATA, *PNDIS_PACKET_OOB_DATA;

Apart from the HeaderSize and Status there really doesnt seem to be too many important things affecting my indication above. How does the checksum offload play into this?

Also there is an array for PACKET_EXTENSION. Is this actually the field thats manipulated by the

NDIS_SET_ORIGINAL_PACKET macro - I presume at least the “OriginalPacket” field is (for OOB). Checksum is part of a different array index. SO how does all this add up. Your detailed explanation witll be appreciated

Thanks
-Johnny

 

From: “Thomas F. Divine”

Reply-To: “NT Developers Interest List”

>To: “NT Developers Interest List”
>Subject: [ntdev] Re: packet indication failing - analysis help reqd.
>Date: Tue, 9 Apr 2002 16:39:27 -0400
>
>TCP/IP probably uses TDI Events for receive. This means that the receive event handler - not the receive handler - would be called. These are not static entry points that you can break on just using a debugger and symbol table.
>
>There may be something missing in the OOB data that you haven’t initialized. For example, examine the NDIS queries that pass through your NDIS IM driver for NDIS Task Offload. If the NIC you are using advertises Rx checksum offload support and your home-brew packet doesn’t initialize OOB data correctly, the packet may simply be ignored. Unfortunately, the DDK doesn’t give an example of how an “active” NDIS IM (does something more then PassThru) must deal with this.
>
>If the NDIS miniport and TCP/IP do setup NDIS task offload, you might just try filtering the OID requesting NDIS task offload capabilities; fail the task offload query in your IM and don’t pass it on to the lower-level miniport. If your driver then works in this simplified environment you at least know where you should look. (Don’t bother doing this if you don’t see NDIS TaskOffload being setup. Too much trouble…)
>
>There may be other reasons, and getting it right takes study and experimentation. It took a while to get PCAUSA’s simple “CryptoPing” to work.
>
>Good luck,
>–
>Thomas F. Divine
>
>PCAUSA - Tools & Resources For Network Software Developers
>NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
><http: www.pcausa.com> - <http: www.rawether.net>
> “Johnny D” wrote in message news:xxxxx@ntdev…
> I receive a packet in myReceivePacket() and then I create own descriptor and chain up my own buffers to it and do an NdisMIndicateReceivePacket to the upperlayer. Before passing the pkt up I make sure I have all the right information and all the expected buffers of expected lengths are chained up. Also, for the desciptor that I create I do
>
> NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket));
>
> I see that my breakpoint for IPRcv is not being hit. Does anyone know what the problem could be ? . How can I set breakpoints to see what happened to the indication … which driver got it… Also since its a deserialized driver, I cant check the status of the pkt after the indicate call, but I set the pkt desc status to NDIS_STATUS_RESOURCES before the indication.
>
> Thanks
> -Johnny
>
> ====----
>
> >
> >From: Michal Vodicka
>
> >
> >Reply-To: “NT Developers Interest List”
> >
> >To: “NT Developers Interest List”
> >
> >Subject: [ntdev] Re: Q on NdisReturnPackets
> >
> >Date: Mon, 8 Apr 2002 23:38:01 +0200
> >
> >
> >
> > > ----------
> >
> > > 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]
> >
> > > >
> >
> > >
> >
> >
> >
> >—
> >
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> >
> >To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
>------------------------------------------------------------------------------
> Chat with friends online, try MSN Messenger: Click Here
>
> >
>
>
>------------------------------------------------------------------------------
> Chat with friends online, try MSN Messenger: Click Here
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%
</http:></http:>

Chat with friends online, try MSN Messenger: Click Here

5

> ----------

From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, April 09, 2002 10:39 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: packet indication failing - analysis help reqd.

TCP/IP probably uses TDI Events for receive. This means that the receive
event handler - not the receive handler - would be called. These are not
static entry points that you can break on just using a debugger and symbol
table.

Thomas, sorry, it is always possible to use a breakpoint at static symbol.
TcpIp registers standard NDIS protocol which contains both ProtocolReceive
and ProtocolReceivePacket handlers and breakpoints should be put there. TDI
layer isn’t involved, yet, I guess Johny’s packet are rejected before
because contain something wrong (for example, packet header). Steping
through mentioned handlers usually help to find problem.

It should be possible to find these handler using ndiskd extension but I’m
not sure. IIRC they are named _ArpRcv and _ArpRcvPacket.

Best regards,

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

6

Johny,

forget about OOB for a while. Simply clear it, set header size (maybe not
necessary), set packet status to resources and indicate it. If it is
rejected, there is something wrong with your packet buffers. It may be IP or
TCP header, checksums etc. Put breakpoint at _ArcRcv and step to see why it
was rejected. When done, you can continue with OOB info.

I mean something like this:

NdisZeroMemory(NDIS_OOB_DATA_FROM_PACKET(NdisPacket),
sizeof(NDIS_PACKET_OOB_DATA));
NDIS_SET_PACKET_HEADER_SIZE(NdisPacket, HeaderBufferSize);
NDIS_SET_PACKET_STATUS(NdisPacket, NDIS_STATUS_RESOURCES);
NdisMIndicateReceivePacket(MiniportAdapterHandle, &NdisPacket, 1);
…

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]
Sent: Wednesday, April 10, 2002 1:35 AM
To: xxxxx@lists.osr.com
Cc: michal.vodicka@st.com; xxxxx@hotmail.com
Subject: Re: [ntdev] Re: packet indication failing - analysis help
reqd.

As per Michals recommendation I am setting the Orignal packet to itself.
But before I do this am I still supposed to set the new packet
descriptor’s Head and Tail to the passed in packets’ Head and Tail. I
bascically will be attaching my own buffers to this new descr, so I
believe, unless its affecting the call to the NDIS_SET_ORIGINAL_PACKET
macro in some way, I dont need this.

I am still not fully clear on the usage of the OOB data and how its
affecting my packet indication. I have been able to pick up bits and
pieces from helpful people like Thomas, Michal and Max. As i understand
OOB data is as follows:

typedef struct _NDIS_PACKET_OOB_DATA {
union {
ULONGLONG TimeToSend;
ULONGLONG TimeSent;
};
ULONGLONG TimeReceived;
UINT HeaderSize;
UINT SizeMediaSpecificInfo;
PVOID MediaSpecificInformation;
NDIS_STATUS Status;
} NDIS_PACKET_OOB_DATA, *PNDIS_PACKET_OOB_DATA;

Apart from the HeaderSize and Status there really doesnt seem to be too
many important things affecting my indication above. How does the checksum
offload play into this?

Also there is an array for PACKET_EXTENSION. Is this actually the field
thats manipulated by the

NDIS_SET_ORIGINAL_PACKET macro - I presume at least the “OriginalPacket”
field is (for OOB). Checksum is part of a different array index. SO how
does all this add up. Your detailed explanation witll be appreciated

Thanks
-Johnny

>From: “Thomas F. Divine”

>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: packet indication failing - analysis help reqd.
>Date: Tue, 9 Apr 2002 16:39:27 -0400
>
>TCP/IP probably uses TDI Events for receive. This means that the receive
event handler - not the receive handler - would be called. These are not
static entry points that you can break on just using a debugger and symbol
table.
>
>There may be something missing in the OOB data that you haven’t
initialized. For example, examine the NDIS queries that pass through your
NDIS IM driver for NDIS Task Offload. If the NIC you are using advertises
Rx checksum offload support and your home-brew packet doesn’t initialize
OOB data correctly, the packet may simply be ignored. Unfortunately, the
DDK doesn’t give an example of how an “active” NDIS IM (does something
more then PassThru) must deal with this.
>
>If the NDIS miniport and TCP/IP do setup NDIS task offload, you might
just try filtering the OID requesting NDIS task offload capabilities; fail
the task offload query in your IM and don’t pass it on to the lower-level
miniport. If your driver then works in this simplified environment you at
least know where you should look. (Don’t bother doing this if you don’t
see NDIS TaskOffload being setup. Too much trouble…)
>
>There may be other reasons, and getting it right takes study and
experimentation. It took a while to get PCAUSA’s simple “CryptoPing” to
work.
>
>Good luck,
>–
>Thomas F. Divine
>
>PCAUSA - Tools & Resources For Network Software Developers
>NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
> -
> “Johnny D” wrote in message news:xxxxx@ntdev…
> I receive a packet in myReceivePacket() and then I create own descriptor
and chain up my own buffers to it and do an NdisMIndicateReceivePacket to
the upperlayer. Before passing the pkt up I make sure I have all the right
information and all the expected buffers of expected lengths are chained
up. Also, for the desciptor that I create I do
>
> NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket));
>
> I see that my breakpoint for IPRcv is not being hit. Does anyone know
what the problem could be ? . How can I set breakpoints to see what
happened to the indication … which driver got it… Also since its a
deserialized driver, I cant check the status of the pkt after the indicate
call, but I set the pkt desc status to NDIS_STATUS_RESOURCES before the
indication.
>
> Thanks
> -Johnny
>
> ====----
>
> >
> >From: Michal Vodicka
>
> >
> >Reply-To: “NT Developers Interest List”
> >
> >To: “NT Developers Interest List”
> >
> >Subject: [ntdev] Re: Q on NdisReturnPackets
> >
> >Date: Mon, 8 Apr 2002 23:38:01 +0200
> >
> >
> >
> > > ----------
> >
> > > 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]
> >
> > > >
> >
> > >
> >
> >
> >
> >—
> >
> >You are currently subscribed to ntdev as: xxxxx@hotmail.com
> >
> >To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>
>-------------------------------------------------------------------------

> Chat with friends online, try MSN Messenger: Click Here
>
> >
>
>
>-------------------------------------------------------------------------

> Chat with friends online, try MSN Messenger: Click Here
>
>
>
>—
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>To unsubscribe send a blank email to %%email.unsub%%

Chat with friends online, try MSN Messenger: Click Here
http:
>
></http:>

7

“Michal Vodicka” wrote in message
news:xxxxx@ntdev…
>
> > ----------
> > From: xxxxx@hotmail.com[SMTP:xxxxx@hotmail.com]
> > Reply To: xxxxx@lists.osr.com
> > Sent: Tuesday, April 09, 2002 10:39 PM
> > To: xxxxx@lists.osr.com
> > Subject: [ntdev] Re: packet indication failing - analysis help reqd.
> >
> >
> > TCP/IP probably uses TDI Events for receive. This means that the receive
> > event handler - not the receive handler - would be called. These are not
> > static entry points that you can break on just using a debugger and
symbol
> > table.
> >
> Thomas, sorry, it is always possible to use a breakpoint at static symbol.
> TcpIp registers standard NDIS protocol which contains both ProtocolReceive
> and ProtocolReceivePacket handlers and breakpoints should be put there.
TDI
> layer isn’t involved, yet, I guess Johny’s packet are rejected before
> because contain something wrong (for example, packet header). Steping
> through mentioned handlers usually help to find problem.
>
You are right, Michael. I am thinking one level higher at TDI Client.

Good night,

Thos

8

Michal,

My indicate still seems to be failing even before we hit IPRcv break point. Interesting to note that all packet ext fields are NULL except

OriginalPacketInfo = 81f2a028

Also:


NdisPacketOobOffset 0078



How do I get OOB data info from this?

Thanks

-Johnny


NDIS_PACKET at 81F2A028



NdisBuffer at 817d1008



Next 8162c208 Size 20



MdlFlags 0000000c Process 0



MappedSystemVa 81613008 Start VA 81613000



ByteCount 000005c0 ByteOffset 8



NdisBuffer at 8162c208



Next 00000000 Size 20



MdlFlags 0000000c Process 0



MappedSystemVa 81615108 Start VA 81615000



ByteCount 0000001c ByteOffset 108



MacReserved:



00000000 00000000 81f83130 00000000



Packet Extension (40 bytes) at 81f2a0c0



0. TcpIpChecksumPacketInfo = 00000000



1. IpSecPacketInfo = 00000000



2. TcpLargeSendPacketInfo = 00000000



3. ClassificationHandlePacketInfo = 00000000



4. HeaderIndexInfo = 00000000



5. ScatterGatherListPacketInfo = 00000000



6. Ieee8021pPriority = 00000000



7. OriginalPacketInfo = 81f2a028



8. NdisInternalExtension1 = 00000000



9. NdisInternalExtension2 = 00000000



00000000 00000000 00000000 00000000 00000000 00000000 00000000 81f2a028 00000000 00000000



Packet.Private (32 bytes)



PhysicalCount 00000002 Total Length 000005f8



Head 817d1008 Tail 8162c208



Pool 81f2a000 Count 00000002



Flags 00000000 ValidCounts 00000000



NdisPacketFlags 00000080 NdisPacketOobOffset 0078



Private.Flags : 00000000



Private.NdisPacketFlags : 00000080



fPACKET_ALLOCATED_BY_NDIS,

— 

From: Michal Vodicka

>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: packet indication failing - analysis help reqd.
>Date: Wed, 10 Apr 2002 01:54:00 +0200
>
>Johny,
>
>forget about OOB for a while. Simply clear it, set header size (maybe not
>necessary), set packet status to resources and indicate it. If it is
>rejected, there is something wrong with your packet buffers. It may be IP or
>TCP header, checksums etc. Put breakpoint at _ArcRcv and step to see why it
>was rejected. When done, you can continue with OOB info.
>
>I mean something like this:
>
>NdisZeroMemory(NDIS_OOB_DATA_FROM_PACKET(NdisPacket),
>sizeof(NDIS_PACKET_OOB_DATA));
>NDIS_SET_PACKET_HEADER_SIZE(NdisPacket, HeaderBufferSize);
>NDIS_SET_PACKET_STATUS(NdisPacket, NDIS_STATUS_RESOURCES);
>NdisMIndicateReceivePacket(MiniportAdapterHandle, &NdisPacket, 1);
>…
>
>Best regards,
>
>Michal Vodicka
>STMicroelectronics Design and Application s.r.o.
>[michal.vodicka@st.com, http:://www.st.com]


Chat with friends online, try MSN Messenger: Click Here

9

I don’t think that this is your problem, but this line is confusing:

NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket));

Shouldn’t it be:

NDIS_SET_ORIGINAL_PACKET(MyPacket, MyPacket );

Thos

“Johnny D” wrote in message news:xxxxx@ntdev…
I receive a packet in myReceivePacket() and then I create own descriptor and chain up my own buffers to it and do an NdisMIndicateReceivePacket to the upperlayer. Before passing the pkt up I make sure I have all the right information and all the expected buffers of expected lengths are chained up. Also, for the desciptor that I create I do

NDIS_SET_ORIGINAL_PACKET(MyPacket, NDIS_GET_ORIGINAL_PACKET(MyPacket));

I see that my breakpoint for IPRcv is not being hit. Does anyone know what the problem could be ? . How can I set breakpoints to see what happened to the indication … which driver got it… Also since its a deserialized driver, I cant check the status of the pkt after the indicate call, but I set the pkt desc status to NDIS_STATUS_RESOURCES before the indication.

Thanks
-Johnny

====----

>
>From: Michal Vodicka

>
>Reply-To: “NT Developers Interest List”
>
>To: “NT Developers Interest List”
>
>Subject: [ntdev] Re: Q on NdisReturnPackets
>
>Date: Mon, 8 Apr 2002 23:38:01 +0200
>
>
>
> > ----------
>
> > 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]
>
> > >
>
> >
>
>
>
>—
>
>You are currently subscribed to ntdev as: xxxxx@hotmail.com
>
>To unsubscribe send a blank email to %%email.unsub%%
>

------------------------------------------------------------------------------
Chat with friends online, try MSN Messenger: Click Here

>

------------------------------------------------------------------------------
Chat with friends online, try MSN Messenger: Click Here

10

Johny,

please read again what I wrote before. You have to trace ARP layer at first.
IP layer is called only if packet passes some basic tests.

From below info I’d guess you attached buffers to packet in reverse order.
It seems as packet body (size 5c0) is attached before header (size 1c). If
it is a case, such a packet is never passed to IP layer.

Your OriginalPacketInfo simply points to your packet. If you haven’t set it,
maybe NDIS did. As for OOB, seach ndis.h or docs for appropriate macros.

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]
Sent: Wednesday, April 10, 2002 3:48 AM
To: xxxxx@lists.osr.com
Cc: xxxxx@storagecraft.com; michal.vodicka@st.com
Subject: Re: [ntdev] Re: packet indication failing - analysis help
reqd.

Michal,

My indicate still seems to be failing even before we hit IPRcv break
point. Interesting to note that all packet ext fields are NULL except

OriginalPacketInfo = 81f2a028

Also:

NdisPacketOobOffset 0078

How do I get OOB data info from this?

Thanks

-Johnny

NDIS_PACKET at 81F2A028

NdisBuffer at 817d1008

Next 8162c208 Size 20

MdlFlags 0000000c Process 0

MappedSystemVa 81613008 Start VA 81613000

ByteCount 000005c0 ByteOffset 8

NdisBuffer at 8162c208

Next 00000000 Size 20

MdlFlags 0000000c Process 0

MappedSystemVa 81615108 Start VA 81615000

ByteCount 0000001c ByteOffset 108

MacReserved:

00000000 00000000 81f83130 00000000

Packet Extension (40 bytes) at 81f2a0c0

  1. TcpIpChecksumPacketInfo = 00000000

  2. IpSecPacketInfo = 00000000

  3. TcpLargeSendPacketInfo = 00000000

  4. ClassificationHandlePacketInfo = 00000000

  5. HeaderIndexInfo = 00000000

  6. ScatterGatherListPacketInfo = 00000000

  7. Ieee8021pPriority = 00000000

  8. OriginalPacketInfo = 81f2a028

  9. NdisInternalExtension1 = 00000000

  10. NdisInternalExtension2 = 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 81f2a028
00000000 00000000

Packet.Private (32 bytes)

PhysicalCount 00000002 Total Length 000005f8

Head 817d1008 Tail 8162c208

Pool 81f2a000 Count 00000002

Flags 00000000 ValidCounts 00000000

NdisPacketFlags 00000080 NdisPacketOobOffset 0078

Private.Flags : 00000000

Private.NdisPacketFlags : 00000080

fPACKET_ALLOCATED_BY_NDIS,

>From: Michal Vodicka
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: packet indication failing - analysis help reqd.
>Date: Wed, 10 Apr 2002 01:54:00 +0200
>
>Johny,
>
>forget about OOB for a while. Simply clear it, set header size (maybe not

>necessary), set packet status to resources and indicate it. If it is
>rejected, there is something wrong with your packet buffers. It may be IP
or
>TCP header, checksums etc. Put breakpoint at _ArcRcv and step to see why
it
>was rejected. When done, you can continue with OOB info.
>
>I mean something like this:
>
>NdisZeroMemory(NDIS_OOB_DATA_FROM_PACKET(NdisPacket),
>sizeof(NDIS_PACKET_OOB_DATA));
>NDIS_SET_PACKET_HEADER_SIZE(NdisPacket, HeaderBufferSize);
>NDIS_SET_PACKET_STATUS(NdisPacket, NDIS_STATUS_RESOURCES);
>NdisMIndicateReceivePacket(MiniportAdapterHandle, &NdisPacket, 1);
>…
>
>Best regards,
>
>Michal Vodicka
>STMicroelectronics Design and Application s.r.o.
>[michal.vodicka@st.com, http:://www.st.com]

Chat with friends online, try MSN Messenger: Click Here
http:
>
></http:>

11

Thanks for pointing that one out, I do break into ARPRcv. I believe since I snipped out the MAC header from the 1st buffer, my packet is mostly getting thrown away as IPRcv never gets hit. My question is then: For every pkt passed up from our IM driver is it a reqd thing to have the MAC header in place? I
I was able to figure out the OOB stuff.

Thanks

-Johnny

 


>From: Michal Vodicka

>Reply-To: “NT Developers Interest List”

>To: “NT Developers Interest List”

>Subject: [ntdev] Re: packet indication failing - analysis help reqd.

>Date: Wed, 10 Apr 2002 04:00:02 +0200

>

>Johny,

>

>please read again what I wrote before. You have to trace ARP layer at first.

>IP layer is called only if packet passes some basic tests.

>

>From below info I’d guess you attached buffers to packet in reverse order.

>It seems as packet body (size 5c0) is attached before header (size 1c). If

>it is a case, such a packet is never passed to IP layer.

>

>Your OriginalPacketInfo simply points to your packet. If you haven’t set it,

>maybe NDIS did. As for OOB, seach ndis.h or docs for appropriate macros.

>

>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]

> > Sent: Wednesday, April 10, 2002 3:48 AM

> > To: xxxxx@lists.osr.com

> > Cc: xxxxx@storagecraft.com; michal.vodicka@st.com

> > Subject: Re: [ntdev] Re: packet indication failing - analysis help

> > reqd.

> >

> > Michal,

> >

> > My indicate still seems to be failing even before we hit IPRcv break

> > point. Interesting to note that all packet ext fields are NULL except

> >

> > OriginalPacketInfo = 81f2a028

> >

> > Also:

> >

> > NdisPacketOobOffset 0078

> >

> > How do I get OOB data info from this?

> >

> >

> > Thanks

> >

> > -Johnny

> >

> > —

> >

> > NDIS_PACKET at 81F2A028

> >

> > NdisBuffer at 817d1008

> >

> > Next 8162c208 Size 20

> >

> > MdlFlags 0000000c Process 0

> >

> > MappedSystemVa 81613008 Start VA 81613000

> >

> > ByteCount 000005c0 ByteOffset 8

> >

> > NdisBuffer at 8162c208

> >

> > Next 00000000 Size 20

> >

> > MdlFlags 0000000c Process 0

> >

> > MappedSystemVa 81615108 Start VA 81615000

> >

> > ByteCount 0000001c ByteOffset 108

> >

> > MacReserved:

> >

> > 00000000 00000000 81f83130 00000000

> >

> > Packet Extension (40 bytes) at 81f2a0c0

> >

> > 0. TcpIpChecksumPacketInfo = 00000000

> >

> > 1. IpSecPacketInfo = 00000000

> >

> > 2. TcpLargeSendPacketInfo = 00000000

> >

> > 3. ClassificationHandlePacketInfo = 00000000

> >

> > 4. HeaderIndexInfo = 00000000

> >

> > 5. ScatterGatherListPacketInfo = 00000000

> >

> > 6. Ieee8021pPriority = 00000000

> >

> > 7. OriginalPacketInfo = 81f2a028

> >

> > 8. NdisInternalExtension1 = 00000000

> >

> > 9. NdisInternalExtension2 = 00000000

> >

> > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81f2a028

> > 00000000 00000000

> >

> > Packet.Private (32 bytes)

> >

> > PhysicalCount 00000002 Total Length 000005f8

> >

> > Head 817d1008 Tail 8162c208

> >

> > Pool 81f2a000 Count 00000002

> >

> > Flags 00000000 ValidCounts 00000000

> >

> > NdisPacketFlags 00000080 NdisPacketOobOffset 0078

> >

> > Private.Flags : 00000000

> >

> > Private.NdisPacketFlags : 00000080

> >

> > fPACKET_ALLOCATED_BY_NDIS,

> >

> > —

> >

> > >From: Michal Vodicka

> > >Reply-To: “NT Developers Interest List”

> > >To: “NT Developers Interest List”

> > >Subject: [ntdev] Re: packet indication failing - analysis help reqd.

> > >Date: Wed, 10 Apr 2002 01:54:00 +0200

> > >

> > >Johny,

> > >

> > >forget about OOB for a while. Simply clear it, set header size (maybe not

> >

> > >necessary), set packet status to resources and indicate it. If it is

> > >rejected, there is something wrong with your packet buffers. It may be IP

> > or

> > >TCP header, checksums etc. Put breakpoint at _ArcRcv and step to see why

> > it

> > >was rejected. When done, you can continue with OOB info.

> > >

> > >I mean something like this:

> > >

> > >NdisZeroMemory(NDIS_OOB_DATA_FROM_PACKET(NdisPacket),

> > >sizeof(NDIS_PACKET_OOB_DATA));

> > >NDIS_SET_PACKET_HEADER_SIZE(NdisPacket, HeaderBufferSize);

> > >NDIS_SET_PACKET_STATUS(NdisPacket, NDIS_STATUS_RESOURCES);

> > >NdisMIndicateReceivePacket(MiniportAdapterHandle, &NdisPacket, 1);

> > >…

> > >

> > >Best regards,

> > >

> > >Michal Vodicka

> > >STMicroelectronics Design and Application s.r.o.

> > >[michal.vodicka@st.com, http:://www.st.com]

> >

> >

> > _____

> >

> > Chat with friends online, try MSN Messenger: Click Here

> > <http: g.msn.com></http:>

> >

> >

>

>—

>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

12

Must have MAC header.
“Johnny D” wrote in message news:xxxxx@ntdev…
Thanks for pointing that one out, I do break into ARPRcv. I believe since I snipped out the MAC header from the 1st buffer, my packet is mostly getting thrown away as IPRcv never gets hit. My question is then: For every pkt passed up from our IM driver is it a reqd thing to have the MAC header in place? I
I was able to figure out the OOB stuff.

Thanks
-Johnny

>From: Michal Vodicka
>Reply-To: “NT Developers Interest List”
>To: “NT Developers Interest List”
>Subject: [ntdev] Re: packet indication failing - analysis help reqd.
>Date: Wed, 10 Apr 2002 04:00:02 +0200
>
>Johny,
>
>please read again what I wrote before. You have to trace ARP layer at first.
>IP layer is called only if packet passes some basic tests.
>
>From below info I’d guess you attached buffers to packet in reverse order.
>It seems as packet body (size 5c0) is attached before header (size 1c). If
>it is a case, such a packet is never passed to IP layer.
>
>Your OriginalPacketInfo simply points to your packet. If you haven’t set it,
>maybe NDIS did. As for OOB, seach ndis.h or docs for appropriate macros.
>
>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]
> > Sent: Wednesday, April 10, 2002 3:48 AM
> > To: xxxxx@lists.osr.com
> > Cc: xxxxx@storagecraft.com; michal.vodicka@st.com
> > Subject: Re: [ntdev] Re: packet indication failing - analysis help
> > reqd.
> >
> > Michal,
> >
> > My indicate still seems to be failing even before we hit IPRcv break
> > point. Interesting to note that all packet ext fields are NULL except
> >
> > OriginalPacketInfo = 81f2a028
> >
> > Also:
> >
> > NdisPacketOobOffset 0078
> >
> > How do I get OOB data info from this?
> >
> >
> > Thanks
> >
> > -Johnny
> >
> > —
> >
> > NDIS_PACKET at 81F2A028
> >
> > NdisBuffer at 817d1008
> >
> > Next 8162c208 Size 20
> >
> > MdlFlags 0000000c Process 0
> >
> > MappedSystemVa 81613008 Start VA 81613000
> >
> > ByteCount 000005c0 ByteOffset 8
> >
> > NdisBuffer at 8162c208
> >
> > Next 00000000 Size 20
> >
> > MdlFlags 0000000c Process 0
> >
> > MappedSystemVa 81615108 Start VA 81615000
> >
> > ByteCount 0000001c ByteOffset 108
> >
> > MacReserved:
> >
> > 00000000 00000000 81f83130 00000000
> >
> > Packet Extension (40 bytes) at 81f2a0c0
> >
> > 0. TcpIpChecksumPacketInfo = 00000000
> >
> > 1. IpSecPacketInfo = 00000000
> >
> > 2. TcpLargeSendPacketInfo = 00000000
> >
> > 3. ClassificationHandlePacketInfo = 00000000
> >
> > 4. HeaderIndexInfo = 00000000
> >
> > 5. ScatterGatherListPacketInfo = 00000000
> >
> > 6. Ieee8021pPriority = 00000000
> >
> > 7. OriginalPacketInfo = 81f2a028
> >
> > 8. NdisInternalExtension1 = 00000000
> >
> > 9. NdisInternalExtension2 = 00000000
> >
> > 00000000 00000000 00000000 00000000 00000000 00000000 00000000 81f2a028
> > 00000000 00000000
> >
> > Packet.Private (32 bytes)
> >
> > PhysicalCount 00000002 Total Length 000005f8
> >
> > Head 817d1008 Tail 8162c208
> >
> > Pool 81f2a000 Count 00000002
> >
> > Flags 00000000 ValidCounts 00000000
> >
> > NdisPacketFlags 00000080 NdisPacketOobOffset 0078
> >
> > Private.Flags : 00000000
> >
> > Private.NdisPacketFlags : 00000080
> >
> > fPACKET_ALLOCATED_BY_NDIS,
> >
> > —
> >
> > >From: Michal Vodicka
> > >Reply-To: “NT Developers Interest List”
> > >To: “NT Developers Interest List”
> > >Subject: [ntdev] Re: packet indication failing - analysis help reqd.
> > >Date: Wed, 10 Apr 2002 01:54:00 +0200
> > >
> > >Johny,
> > >
> > >forget about OOB for a while. Simply clear it, set header size (maybe not
> >
> > >necessary), set packet status to resources and indicate it. If it is
> > >rejected, there is something wrong with your packet buffers. It may be IP
> > or
> > >TCP header, checksums etc. Put breakpoint at _ArcRcv and step to see why
> > it
> > >was rejected. When done, you can continue with OOB info.
> > >
> > >I mean something like this:
> > >
> > >NdisZeroMemory(NDIS_OOB_DATA_FROM_PACKET(NdisPacket),
> > >sizeof(NDIS_PACKET_OOB_DATA));
> > >NDIS_SET_PACKET_HEADER_SIZE(NdisPacket, HeaderBufferSize);
> > >NDIS_SET_PACKET_STATUS(NdisPacket, NDIS_STATUS_RESOURCES);
> > >NdisMIndicateReceivePacket(MiniportAdapterHandle, &NdisPacket, 1);
> > >…
> > >
> > >Best regards,
> > >
> > >Michal Vodicka
> > >STMicroelectronics Design and Application s.r.o.
> > >[michal.vodicka@st.com, http:://www.st.com]
> >
> >
> > _____
> >
> > Chat with friends online, try MSN Messenger: Click Here
> >
> >
> >
>
>—
>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