NDIS Driver blocks all traffic after having blocked many consecutive data packets. Follow up 1.

Thanks a lot for your reply, Thomas F. Divine!

Your question was:
A key question is: In this “blocked” condition do packets continue to be received at your ProtocolReceive or ProtocolReceivePacket handlers?
If the answer is yes, packets continue to be received, then I guess the higher-level is actually causing the blockage.
If the answer is no, packets are no longer being received, then the NIC or lower-level miniport may have entered a low-resource condition that you aren’t handling properly. Your filter may not be handling the NDIS_STATUS_RESOURCES flag in your ProtocolReceivePacket handler or your ProtocolReceive handler may not be fully implemented.

The answer to your question is not that obvious. If no transmitted (requesting) packets are being sent usually there are no incoming packets… In the KdPrints I see that the last request before the blockages always was a requesting package. As one of those often means more than one incoming packet to me it looks like the receiving packets are suddenly being blocked.

As you might have guessed I’m not handling the NDIS_STATUS_RESOURCES stati apart from what the original driver already does. I have now put KdPrints to see if status NdisDprAllocatePacket == NDIS_STATUS_RESOURCES in PtReceivePacket indeed occurs occasionally when many consecutive incoming packets are being blocked (is it that what you mean?). As you know this case is not explicitely coded in the original passthru driver.
PtReceive is fully implemented too.

I have overseen a small, but possibly important detail: When I blocked packages in PtReceivePacket I returned 0 (correct) and I also returned 0 in PtReceive (incorrect), changed to NDIS_STATUS_FAILURE.

Does it make sense when (on my computer)

  • there is a connection via the (W)LAN PtReceive is called and
  • when the connection is via an aircard PtReceivePacket is called most of the time (99 or more out of 100)?
    When the blockages occurred I had a LAN connection.

In the meantime I’ve changed the country where I do the tests and in this new environment (connection is via an aircard) there are no unrequested incoming packets. I’m still busy to find and test programs and/or websites which are going to send packets to my IP address. I’ve yet to try some options with nmap, but I think need 2 computers with 2 different IP addresses.

It looks like you unfortunately can not ping or send any packets from your computer to your own IP (“loopback mode”, not localhost).
Is this assumption correct? Is there a trick to circumvent that restriction? (I get timeouts (not an error message…) when I ping my own IP.)
Likewise, pings to localhost (127.0.0.1) are not shown in the NDIS driver, so testing is not that easy.

Any suggestions how to best test firewalls?

I’ll let you know about the results as soon as I know more.

Michael Keller