Problem with NdisMIndicateReceivePacket.

NTDEV
1

Hello everyone,

I am currently developing an encryption IM driver. The problem, I have, is
linked to the call of NdisMIndicateReceivePacket. I have tested my IM driver
on many different computers with many different network adapters. In some
cases (few but still too many), the call to NdisMIndicateReceivePacket never
returns. I have read some previous posts on this newsgroup and on the
Internet, I tried some modifications without any effect.

  • For the problem of OID_TCP_TASK_OFFLOAD : In the function
    MiniportQueryInformation I return NDIS_STATUS_NOT_SUPPORTED.

  • Before calling NdisMIndicateReceivePacket, I call
    NDIS_SET_PACKET_HEADER_SIZE and NDIS_SET_PACKET_STATUS (packet,
    NDIS_STATUS_RESOURCES).

As I told before, in most cases, the encryption IM driver works fine, in the
other cases, this function never returns.
What’s more, as this function is called inside a SpinLock, when it doesn’t
return, the computer totally freezes.

I run a debug check with these cases. The function doesn’t return on the
first TCP packet I receive. It is often a SYN/ACK Packet.

If someone has an idea to help, I would be grateful.
If needed, I can paste portions of codes here to be more explicit.

Thank you in advance.
Renaud Roques.

PS.: I did not specify it, but as it is an encryption IM driver the original
packet received by ProtocolReceive is of course modified before calling
NdisMIndicateReceivePacket.
?

2

Renaud,

>What’s more, as this function is called inside a SpinLock

Bad idea. AFAIK you must not be holding *any* locks when indicating a
receive packet. As an IM driver you should definitely be deserialized.
Taking a lock why processing a receive is fine but you must release the lock
before calling NDIS to further indicate the packet to bound protocols. The
protocol is free to send a packet during that indication (on the same
processor) and the NIC (or NDIS) beneath you is free to loop it back right
into your receive processing again. If you were to be holding a lock and
tried to re-acquire it, bad things will happen (to say the least).

I cannot say that this is your problem but I would not go much further
without solving the structural problem. Have you run this on the checked
build and reproduced this failure?

Also, since you are modifying the packet I am going to assume that you:

  • Make an entirely new NDIS_PACKET, NDIS_BUFFER (list), etc. The packet is
    ‘read-only’ to you.
  • The ‘new’ packet is disassociated from the original packet. In other
    words, it does not try to claim that ‘original’ packet is the same as the
    indicated packet’s ‘original packet’.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

3

Thank you very much. It works with the call outside of the Spinlock.

Renaud ROQUES
IT Security Engineer

-----Message d’origine-----
De?: xxxxx@lists.osr.com [mailto:bounce-263955-
xxxxx@lists.osr.com] De la part de David R. Cattley
Envoy??: mercredi 27 septembre 2006 16:08
??: Windows System Software Devs Interest List
Objet?: RE: [ntdev] Problem with NdisMIndicateReceivePacket.

Renaud,

>>What’s more, as this function is called inside a SpinLock

Bad idea. AFAIK you must not be holding *any* locks when indicating a
receive packet. As an IM driver you should definitely be deserialized.
Taking a lock why processing a receive is fine but you must release the
lock
before calling NDIS to further indicate the packet to bound protocols.
The
protocol is free to send a packet during that indication (on the same
processor) and the NIC (or NDIS) beneath you is free to loop it back right
into your receive processing again. If you were to be holding a lock and
tried to re-acquire it, bad things will happen (to say the least).

I cannot say that this is your problem but I would not go much further
without solving the structural problem. Have you run this on the checked
build and reproduced this failure?

Also, since you are modifying the packet I am going to assume that you:

  • Make an entirely new NDIS_PACKET, NDIS_BUFFER (list), etc. The packet
    is
    ‘read-only’ to you.
  • The ‘new’ packet is disassociated from the original packet. In other
    words, it does not try to claim that ‘original’ packet is the same as the
    indicated packet’s ‘original packet’.

Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

4

>What’s more, as this function is called inside a SpinLock, when it doesn’t

You must not call NdisMIndicateReceivePacket from under a spinlock, period.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com