Hi,
I want to write a lower filter driver for tcp/ip driver so that I can modify the packets coming out or in to it. I can not write a NDIS filter driver because in my case ( using a different NIC that uses tcp offloading engine ) the tcp packets do not go through NDIS filter driver. The tcp packets in this case go form tcp/ip driver to a third party driver directly. What kind of driver I need to write?
>The tcp packets in this case go form tcp/ip driver to a third party driver directly.
How do you think this may be even possible??? How on Earth could TCPIP (I.e. a protocol driver)
send packets to NIC miniport if it was not using NDIS library??? Look - NDIS library is sort of a glue
that holds the network stack together. For example, you can write WDM or WDF NIC driver, but, unless you find a way to expose it to NDIS (directly or as a layered miniport driver) , the existing protocol drivers would be unable to make any use of it. If it was not for NDIS, protocol drivers would be unable to learn about the target NIC’s very existence.
What kind of driver I need to write?
What you need to do now is to read the docs about NDIS and to examine ndis.h header - although largely undocumented, this header reveals more info about NDIS internals than all docs combined
Anton Bassov
Sure tcpip.sys is using NDIS library…
…but isn’t the question rather:
Do NDIS Filter Drivers (and/or Intermediate Drivers) see TCP packet content which is directly communicated to and from the miniport via NDIS offload features (e.g. “TCP Chimney Offload”)?
I assume that the answer to this question is “no”. Otherwise this thread probably wouldn’t exist.
I assume that a WFP callout driver (Windows Filtering Platform) could make these TCP packets accessible. However, OP needs to check if this interferes with the “TCP Chimney Offload” feature or even turns it off on all network adapters.
Marcel Ruedinger
datronicsoft
> …but isn’t the question rather: Do NDIS Filter Drivers (and/or Intermediate Drivers) see
TCP packet content which is directly communicated to and from the miniport
via NDIS offload features (e.g. “TCP Chimney Offload”)?
I assume that the answer to this question is “no”. Otherwise this thread probably wouldn’t exist.
I would not be too sure about LWF, but, as long as we are speaking about NDIS IM, the answer has to be be positive, taking into consideration that,from the protocol driver’s perspective, NDIS IM is, actually, a miniport driver.
What makes me so certain? Don’t forget that, in case of NDIS IM sitting in between miniport and protocol drivers, the opaque MiniportAdapterContext parameter that all protocol drivers supply in miniport-related NDIS function calls, is related to NDIS IM, rather than to an actual miniport driver.
Therefore, NDIS IM is the only entity who, given above mentioned NDIS handle, is capable of providing its corresponding ACTUAL adapter context (i.e the one that miniport drivers provides in a call to NdisMSetMiniportAttributes()).
This is the reason why I am advising the OP to check NDIS headers, as well as to do a bit of disasm - at this point everything will become obvious to him…
Anton Bassov
Same here: I was unsure for a moment about NDIS Filter Driver (LWF). Meanwhile, however, I noticed that reading the instruction manual sometimes really does help. Microsoft Docs actually seem to state how to do TCP offload in a NDIS Filter Driver (LWF). Thus there should be two options:
-
Use WDK network/ndis/filter sample (and read the WDK Docs how to add TCP offload capabilities).
-
Use a WDK sample for WFP Callout Driver e.g. network/trans/stmedit (and possibly analyze how it goes along with network adapter TCP offload capabilities).
It would be very interesting to hear OP research and analysis feedback which one of the two fits the requirements better (and of course for which reasons)…
Marcel Ruedinger
datronicsoft