Asynchronous send or recv in NETWORK layer will affect ALE flow established layer? RRS feed

  • Question

  • hi,

    i has develop a wfp driver called VmsecNetFilter.sys,the driver work at FWPM_LAYER_INBOUND_IPPACKET_V4 and FWPM_LAYER_OUTBAND_IPPACKET_V4 layer,and the driver callout is very simple:copy or clone the ip packet to an entry_list, then return FWP_ACTION_BLOCK with FWPS_CLASSIFY_OUT_FLAG_ABSORB. A system thread get the packet from entry_list, recalculte ip checksum,then call FwpsInjectNetworkSendAsync and FwpsInjectNetworkReceiveAsync send or recv ip packet asynchronously.it wokers very well.

    And now,i need develop a driver that can statistics tcp connection counts.i find the FWPM_LAYER_ALE_FLOW_ESTABLISHED_V4 can implement this functionality,because the MSDN says:A filter at the FWPM_LAYER_ALE_FLOW_ESTABLISHED_V{4|6} layer is matched after a TCP three-way handshake has successfully completed! so I modify wdk sample called stmedit,the stmedit registry ALE_FLOW_ESTABLISHED layer, and when a tcp three-way handshake has completed,the ALE_FLOW_ESTABLISHED callout called,when connect or accept an no existing tcp port,the ALE_FLOW_ESTABLISHED callout will not be called.it workes very well too.

    But,when i install the two work-well driver at a computer A,it works not well.After two driver installed in computer A,in another computer B,connect computer A with an no existing port,for example 8888,B send SYN

    packet to A,then A send RST packet to B,this TCP connection can not established!BUT in computer A,the stmedit.sys ALE_FLOW_ESTABLISHED called!The three-way handshake failed but ALE_FLOW_ESTABLISHED callout called!So ,i debug the stmedit,when callout called,the thread stack as Below:

    RetAddr           : Args to Child                                                           : Call Site
    fffff880`0140cc62 : 00000000`00000000 fffff880`02b8aa30 fffff880`02b8aa30 00000000`00000000 : StmEdit!StreamEditFlowEstablishedClassify [e:\code\example\windows-driver-samples-master\network\trans\stmedit\sys\streamedit.c @ 390]
    fffff880`01404f68 : fffffa80`01cb0034 fffff880`02b8a848 fffffa80`036ecd68 fffffa80`03dcdb00 : NETIO!ProcessCallout+0x1a2
    fffff880`014065e2 : 00000000`00000034 fffff880`02b8a848 fffff880`02b8aa30 fffff880`00000000 : NETIO!ArbitrateAndEnforce+0x238
    fffff880`0171c819 : fffff880`02b8aa30 fffff880`02b8a848 00000000`00000000 fffffa80`03dcdb00 : NETIO!KfdClassify+0x934
    fffff880`017a2562 : fffffa80`01e5fb50 fffff880`017e2830 fffffa80`036ecd10 00000000`00000000 : tcpip!WfpAleClassify+0x49
    fffff880`017364f5 : 00000000`00000000 00000000`00000000 00000000`00000000 fffffa80`036ecd10 : tcpip!WfpAlepFlowEstablishedNotification+0x752
    fffff880`016e292a : 00000000`00000001 fffff880`017e2830 00000000`00000006 00000000`00000000 : tcpip! ?? ::FNODOBFM::`string'+0xdd15
    fffff880`0171c45e : 00000000`00000000 fffff880`02b8b1a8 fffff880`02b8b1a0 fffff880`02b8b128 : tcpip!WfpAleConnectAcceptIndicate+0x19a
    fffff880`016dbe44 : 00000000`00000000 fffffa80`01d6d4f8 00000000`00000002 00000000`00000014 : tcpip!ProcessALEForTransportPacket+0x5fe
    fffff880`016f6d15 : 00000000`00000000 fffffa80`00000000 00000000`e000b822 fffff880`e0008afb : tcpip!WfpProcessOutTransportStackIndication+0x334
    fffff880`017c639f : 00000000`00000000 fffff880`01809900 fffff880`018099a0 fffffa80`01e5fb50 : tcpip!IppSendDatagramsCommon+0x525
    fffff880`018a510d : 00000000`00000001 00000000`00000000 00000000`00000000 fffffa80`03dcdb00 : tcpip!IppInspectInjectRawSend+0x15f
    fffff880`04d32d79 : fffff880`0217b000 fffffa80`041ca190 fffffa80`041ca100 fffffa80`00000001 : fwpkclnt!FwpsInjectNetworkSendAsync0+0x1c1
    fffff880`04d32fdc : 00000000`00000028 fffffa80`03dcdb00 fffffa80`03a17ce0 00000000`00000008 : VmsecNetFilter+0x6d79
    fffff880`04d33039 : fffffa80`03cf6c70 00000000`00000000 fffff880`00000001 fffff880`04d3c110 : VmsecNetFilter+0x6fdc
    fffff880`04d33659 : fffffa80`03a17ce0 00000000`00000000 fffffa80`03a17ce0 fffff680`00000004 : VmsecNetFilter+0x7039
    fffff800`0419f71b : 00000000`00000001 fffffa80`03cd2870 00000000`00000000 fffffa80`03a17ce0 : VmsecNetFilter+0x7659

     the vmsecnetfilter.sys called FwpsInjectNetworkSendAsync send an RST packet but cause stmedit.sys ALE_FLOW_ESTABLISHED be called!i feel very magical.when I stop the vmsecnetfilter.sys,the stmedit.sys ALE_FLOW_ESTABLISHED callout will not be called if the three-way handshake failed.

    why send or recv ip packet asynchronously cause the problem?

    Friday, April 17, 2020 5:47 AM