Prev: USB Imaging Device Driver
Next: PCL5e and PCL6
From: Magnus on 7 Sep 2005 03:54
I'm extending the passthru example to create an IM-driver that
redirects sent/received packets. Everything works well when using NDIS
5.1 and the ProtocolReceivePacket but I run into problems using NDIS
4.0 and ProtocolReceive.


In the ProtocolReceive I get the original packet with
NdisGetReceivedPacket which works (for now I ignore drivers that
don't support this call but will later on take care of the
LookAheadBuffer etc). Once I get the packet I do the same thing as when
using ProtocolReceivePacket - allocate a packet, allocate a buffer,
copy data between packets with NdisCopyFromPacketToPacket
(NdisCopyFromPacketToPacketSafe when doing NDIS 5.1), change the
destinationport and update the checksum, NDIS_SET_ORIGINAL_PACKET,
NDIS_SET_PACKET_HEADER_SIZE, set flags, set status and then indicate
the packet up with NdisMIndicateReceivePacket.


The problem is that the packet never gets to the upper layer when
ProtocolReceive is used, but everything is working great when
ProtocolReceivePacket is used.


I've read something about that you need to supply a buffer that is
atleast the lookahead length but I guess this doesn't apply when using
NdisMIndicateReceivePacket with a complete NDIS_PACKET where the
NDIS_BUFFER holds the entire packet?


Any suggestions of why I get this behaviour? Do you think it would work
better if I used the NdisMEthIndicateReceive instead of the
NdisMIndicateReceivePacket? It would be nice to be able to use the same
code for both PtReceive and PtReceivePacket - that is using the
NdisMIndicateReceivePacket.


I would really appreciate your help.


Magnus Hedbeck
(my email is not valid, reply in newsgroup)

From: Stephan Wolf [MVP] on 9 Sep 2005 05:59
IIRC, NDIS 4 has a completely different concept for intermediate
drivers than NDIS 5.

What do you mean by "using NDIS 4.0"? Is this an old Windows version
that does not support NDIS 5? Or does your protocol claim to only
support NDIS 4?

What is this "protocol"? Did you write a test protocol that sits on top
of your IM or is this the protocol part of the IM itself?

Yes, in general, the first NDIS_BUFFER of an NDIS_PACKET must always be
at least the size of the OID_GEN_CURRENT_LOOKAHEAD.

I guess the following might help:

"Packets Passed by Calling NdisMIndicateReceivPacket Are Ignored
(TCP/IP ReceivePacket Handler Bug)"
http://www.ndis.com/pcakb/KB01060101.htm

[Tom: Typo in the function name: ...Receiv*e*...]

Stephan
---
Magnus wrote:
> I'm extending the passthru example to create an IM-driver that
> redirects sent/received packets. Everything works well when using NDIS
> 5.1 and the ProtocolReceivePacket but I run into problems using NDIS
> 4.0 and ProtocolReceive.
>
>
> In the ProtocolReceive I get the original packet with
> NdisGetReceivedPacket which works (for now I ignore drivers that
> don't support this call but will later on take care of the
> LookAheadBuffer etc). Once I get the packet I do the same thing as when
> using ProtocolReceivePacket - allocate a packet, allocate a buffer,
> copy data between packets with NdisCopyFromPacketToPacket
> (NdisCopyFromPacketToPacketSafe when doing NDIS 5.1), change the
> destinationport and update the checksum, NDIS_SET_ORIGINAL_PACKET,
> NDIS_SET_PACKET_HEADER_SIZE, set flags, set status and then indicate
> the packet up with NdisMIndicateReceivePacket.
>
>
> The problem is that the packet never gets to the upper layer when
> ProtocolReceive is used, but everything is working great when
> ProtocolReceivePacket is used.
>
>
> I've read something about that you need to supply a buffer that is
> atleast the lookahead length but I guess this doesn't apply when using
> NdisMIndicateReceivePacket with a complete NDIS_PACKET where the
> NDIS_BUFFER holds the entire packet?
>
>
> Any suggestions of why I get this behaviour? Do you think it would work
> better if I used the NdisMEthIndicateReceive instead of the
> NdisMIndicateReceivePacket? It would be nice to be able to use the same
> code for both PtReceive and PtReceivePacket - that is using the
> NdisMIndicateReceivePacket.
>
>
> I would really appreciate your help.
>
>
> Magnus Hedbeck
> (my email is not valid, reply in newsgroup)

 | 
Pages: 1
Prev: USB Imaging Device Driver
Next: PCL5e and PCL6