none
Raw TCP packets dropped when sent via FwpsInjectNetworkSendAsync RRS feed

  • Question

  • I registered a filter at FWPM_LAYER_OUTBOUND_IPPACKET_V4, where I copy each ipv4 NET_BUFFER_LIST to a buffer and reinject it unmodified from a worker thread. I'm using FWPM_SUBLAYER_UNIVERSAL as a sublayer FWIW. Basically:

    mdl = IoAllocateMdl(buffer, ...)

    MmBuildMdlForNonPagedPool(mdl);

    FwpsAllocateNetBufferAndNetBufferList0(..., mdl, ..., &nbl)

    FwpsInjectNetworkSendAsync0(..., nbl, ...)

    which returns 0, as well as NET_BUFFER_LIST_STATUS() from the sendComplete callback.

    This works for UDP and ICMP (I get replies back), but not for TCP packets. I can see the SYN going out in NetMon from a virtual machine where I'm testing, but NetMon doesn't see the packet coming outside (in the host machine). And no reply from the remote host of course. 

    I tried updating the IP checksum (which I get as 0 in the classifyFn) and it doesn't change anything. The TCP checksum is already correct when my classifyFn receives it (as far as NetMon can tell). I looked at the original nbl, my flat buffer and the newly created nbl and they all contain the IP packet (starting with 0x45, etc).

    Do I have to create a new sublayer for the filter ? Are the packets dropped because I'm calling sendAsync from a worker thread associated with the system process ? 

    Thanks,

    Bogdan


    • Edited by Harjoc Bogdan Sunday, May 4, 2014 7:26 PM minor code formatting
    Sunday, May 4, 2014 7:25 PM

Answers

  • Replying to my own question: apparently updating all the checksums (including tcp/udp) before reinjecting the packet solves the issue.
    • Marked as answer by Harjoc Bogdan Tuesday, May 6, 2014 12:42 PM
    Tuesday, May 6, 2014 12:41 PM

All replies

  • Also tried enabling WFP auditing, netsh wfp capture, enabling event reporting in advfirewall and got no useful events in event viewer except "connection allowed". 
    Monday, May 5, 2014 8:39 AM
  • Replying to my own question: apparently updating all the checksums (including tcp/udp) before reinjecting the packet solves the issue.
    • Marked as answer by Harjoc Bogdan Tuesday, May 6, 2014 12:42 PM
    Tuesday, May 6, 2014 12:41 PM