Re: Problem about ProtocolReceive()

NTDEV
1

Questions:

a) Assume we only received part of the data in header and lookahead
buffer. If we are to create our own packet, what should be done?

  1. Create a new packet
  2. Call NdisTransferData to fill in the packet.
  3. Chain in header and lookahead buffer.
  4. What else? What about packet flags, OOB?

b) The doc mentioned about NdisGetReceivedPacket. Can we do that to get
the complete packet instead of calling NdisTransferData?

Thanx,
Terence

2

> ----------

From: xxxxx@netvigator.com[SMTP:xxxxx@netvigator.com]
Reply To: xxxxx@lists.osr.com
Sent: Sunday, October 06, 2002 6:13 AM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Problem about ProtocolReceive()

Questions:

a) Assume we only received part of the data in header and lookahead
buffer. If we are to create our own packet, what should be done?

  1. Create a new packet
  2. Call NdisTransferData to fill in the packet.
  3. Chain in header and lookahead buffer.
  4. What else? What about packet flags, OOB?

No.

  1. Allocate new packet descriptor from pre-allocated pool.
  2. Chain enough buffer(s) for all data + header.
  3. Copy header + lookahead buffer contents to new packet if there is full
    packet in lookahead buffer (common situation) or call NdisTransferData
    otherwise. Note it should be possible to copy only rest of packet but I
    found some problems there in the past and had to use above logic instead.
  4. Because original packet isn’t available, you don’t have nor OOB or flags.

b) The doc mentioned about NdisGetReceivedPacket. Can we do that to get
the complete packet instead of calling NdisTransferData?

Sometimes. It may not be available. Also note that, regardless of docs says,
it returns the original received packet descriptor and not what underlying
driver passed up. It may cause problems when some underlying driver changes
data contents (decryption, for example).

Best regards,

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

3

Are the following steps correct?

If the lookahead buffer does not contain the complete packet, I should

Step 1) Chain enough buffer for NdisTransferData.

Will NdisTransferData also fill in the header + lookahead? If not, then I
also need to

Step 2) Copy header + lookahead to a new buffer and chain them to the
beginning.

If OOB is available, I will do the next step

Step 3) NdisGetReceivedPacket and do NDIS_SET_ORIGINAL_PACKET( ,
NDIS_GET_ORIGINAL_PACKET( ));

After NdisMIndicateReceive returned, I can free both the packet and the
buffers.

4

> ----------

From: xxxxx@netvigator.com[SMTP:xxxxx@netvigator.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, October 08, 2002 2:25 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Problem about ProtocolReceive()

Are the following steps correct?

If the lookahead buffer does not contain the complete packet, I should

Step 1) Chain enough buffer for NdisTransferData.

Will NdisTransferData also fill in the header + lookahead? If not, then I
also need to

Header isn’t copied, packet body depends on ByteOffset paramer. See docs for
this function.

Step 2) Copy header + lookahead to a new buffer and chain them to the
beginning.

According to docs, it should by possible to copy header and lookahead and
use NdisTransferData for the rest of packet. As I wrote, I had problems with
it but it was long time before and maybe it is already solved.

If OOB is available, I will do the next step

Step 3) NdisGetReceivedPacket and do NDIS_SET_ORIGINAL_PACKET( ,
NDIS_GET_ORIGINAL_PACKET( ));

Fine but it isn’t enough. At least header size should be set also. See docs
for NDIS_PACKET_OOB_DATA, it is pretty detailed.

After NdisMIndicateReceive returned, I can free both the packet and the
buffers.

General answer is “NO!” but there are special cases. Again, see docs for
this function.

I would recommend to carefully study NDIS docs at first, play with passthru
and debugger at the second and then ask about possible problems or
clarification here. Also, study other network examples in the DDK and see
PCAUSA web site (http://www.pcausa.com) for more info.

Best regards,

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