Thanks James,
For PtReceivePacket, I solved that problem. Actually I was setting the total
length field in IP header to a wrong value (say 1500).As there was no
problem in checksums, therefore the packet was delivered to network layer
and I was getting the packet in Ethereal. but I guess, IP was ignoring the
packet because it didn’t get the complete packet (original packet was having
only 60-70 bytes and total length was set to 1500).
For ProtocolReceive, I am still not sure that my logic is right or not. And
worse thing is that I can’t test this as in miniport layer below me always
calls NdisMIndicateReceivePacket and hence my PtReceivePacket handler is
called and not PtReceive. Here is the logic, I coded. Can you please have a
look and give me some suggestions:
PtRecive:
Step 1. Check whether original packet has to be sent or changed one.
Step 2. Get the contents of the packet. using NdisGetReceivedPacket,
NdisTransferData KPIs.
Step 3. If original, then send it and return NDIS_STATUS_SUCCESS
Step 4. If changed one, then allocate my buffer and packet. Insert this
packet into my linked list. Copy the flags and private sections also. return
NDIS_STATUS_SUCCESS
Step 5.
Amit Manocha
“James Antognini” wrote in message
news:xxxxx@ntdev…
>
> I presume you’ve skipped the NDIS 5.1 section dealing with reusing the
> original packet descriptor. I further presume that you’ve pointed
> Private.Head to your new packet area and Private.Tail to null.
>
> I’ve done this sort of thing successfully, with PtReceive (not with
> PtReceivePackets), pretty much along the lines of what you describe, for
> the path where the packet descriptor is made available via
> NdisGetReceivedPacket. But if you want to send me the code or post it
> here, I can take a look.
>
> –
> If replying by e-mail, please remove “nospam.” from the address.
>
> James Antognini
> Windows DDK MVP
>
>
>
>