FwpsInjectNetworkSendAsync0 vs FwpsInjectTransportSendAsync

NTDEV
1

My Callout currently gets registered to the OUTBOUND_TRANSPORT layer.
Is it allowed to use FwpsInjectNetworkSendAsync0 (I need to set the source IP)?
It seems to work, however I am experiencing a memory leak:

Wfpn   1011615    663619568          0            0	WFP NBL info container , Binary: netio.sys
Fwpn   1011608    404643200          0            0	WFP NBL info , Binary: fwpkclnt.sys
NDnd   1011655    210574464          0            0	NDIS_TAG_POOL_NDIS , Binary: ndis.sys
Fwpi   1011607     48557136          0            0	WFP injector info , Binary: fwpkclnt.sys
Fwpc   1011607     48557136          0            0	WFP injection call context , Binary: fwpkclnt.sys

What about FwpsInjectNetworkReceiveAsync0 vs FwpsInjectTransportReceiveAsync0?

2

WFP NBL info container is fixed now, but the NDIS_TAG_POOL_NDIS one still occurs. Could it be because somehow FwpsInjectNetwork(Receive|Send)Async are not supposed to be used in OUTBOUND_TRANSPORT?

3

Thinking about it, it seems like there should be no way for Fwps to tell from which layer the “original” packet got received - Unless FwpsAllocateCloneNetBufferList or FwpsConstructIpHeaderForTransportPacket0 note this information in some opaque member (e.g. NetBuffer->NetBufferListInfo).

Maybe I will try to create a new NetBufferList “from scratch” and inject that.

4

Thinking about it, Fwps should not be able to tell where the “original packet” came from - Unless either FwpsAllocateCloneNetBufferList or FwpsConstructIpHeaderForTransportPacket0 save this info in some opaque struct member (e.g. NetBuffer->NetBufferListInfo).

I might try to clone the NetBufferList manually “from scratch”.

5

For the record… The problem was that FwpsConstructIpHeaderForTransportPacket0 extended the NBL, and the freeing-routine that I had in place did not account for that.

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.