locked
problem with calling FwpsInjectNetworkSendAsync RRS feed

  • Question

  • FwpsInjectNetworkSendAsync returns success,but the Status in netBufferList from completion pfn is"STATUS_DATA_NOT_ACCEPTED"(0xC000021B)

    i've done some reseach,people just say it happens when the netBufferList contains more than one netbuffer. but it's not in my situation.

    one more thing,i call FwpsInjectNetworkSendAsync many times ,but the issue only occur at the first time..after that it succeed all the time

    anyway,there are some clues i found:

    kd> dt netBufferList
    Local var @ 0x8078ad80 Type _NET_BUFFER_LIST*
    0x87276e48 
       +0x000 Next             : (null) 
       +0x004 FirstNetBuffer   : 0x87276ee8 _NET_BUFFER
       +0x000 Link             : _SLIST_HEADER
       +0x008 Context          : (null) 
       +0x00c ParentNetBufferList : (null) 
       +0x010 NdisPoolHandle   : 0x868c7b80 Void
       +0x018 NdisReserved     : [2] (null) 
       +0x020 ProtocolReserved : [4] (null) 
       +0x030 MiniportReserved : [2] (null) 
       +0x038 Scratch          : (null) 
       +0x03c SourceHandle     : (null) 
       +0x040 NblFlags         : 0
       +0x044 ChildRefCount    : 0n0
       +0x048 Flags            : 0x1200100
       +0x04c Status           : 0n0
       +0x050 NetBufferListInfo : [13] (null) 
    kd> !ndiskd.nbl 0x87276e48 
        NBL                87276e48            Next NBL           NULL
        First NB           87276ee8            Source             NULL
        Flags              01200100 [Unrecognized flags 01200000]
            ↑ NBL_ALLOCATED

    kd> dt netBufferList -r1
    Local var @ 0x8d5d0a74 Type _NET_BUFFER_LIST*
    0x87276e48 
       +0x000 Next             : (null) 
       +0x004 FirstNetBuffer   : 0x87276ee8 _NET_BUFFER
          +0x000 Next             : (null) 
          +0x004 CurrentMdl       : 0x8738f198 _MDL
          +0x008 CurrentMdlOffset : 0
          +0x00c DataLength       : 0x28
          +0x00c stDataLength     : 0x28
          +0x010 MdlChain         : 0x8738f198 _MDL
          +0x014 DataOffset       : 0
          +0x000 Link             : _SLIST_HEADER
          +0x018 ChecksumBias     : 0
          +0x01a Reserved         : 0
          +0x01c NdisPoolHandle   : 0x868c7b80 Void
          +0x020 NdisReserved     : [2] (null) 
          +0x028 ProtocolReserved : [6] (null) 
          +0x040 MiniportReserved : [4] (null) 
          +0x050 DataPhysicalAddress : _LARGE_INTEGER 0x0
       +0x000 Link             : _SLIST_HEADER
          +0x000 Alignment        : 0x87276ee8`00000000
          +0x000 Next             : _SINGLE_LIST_ENTRY
          +0x004 Depth            : 0x6ee8
          +0x006 Sequence         : 0x8727
       +0x008 Context          : (null) 
       +0x00c ParentNetBufferList : (null) 
       +0x010 NdisPoolHandle   : 0x868c7b80 Void
       +0x018 NdisReserved     : [2] (null) 
       +0x020 ProtocolReserved : [4] (null) 
       +0x030 MiniportReserved : [2] (null) 
       +0x038 Scratch          : (null) 
       +0x03c SourceHandle     : (null) 
       +0x040 NblFlags         : 0
       +0x044 ChildRefCount    : 0n0
       +0x048 Flags            : 0x1000100
       +0x04c Status           : 0n-1073741285
       +0x050 NetBufferListInfo : [13] (null) 

    the first netBufferList comes from the successful situation, and the latter is not.

    what does the "Flags" says, since the windbg cant tell..........


    Thursday, November 7, 2013 3:25 AM

All replies

  • You can get DATA_NOT_ACCEPTED if another filter drops the injected packet, the IP header is mal formatted, or injection of a chain. The flag you indicate is internal and essentially indicates a successful injection of the clone.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Saturday, November 9, 2013 12:43 AM
    Moderator
  • that's weird since it only happens at the first time, and there are no third-part firewall

    beside that the packt does not come from clone, i allocate with a MDL, and the netbuffer data is just a tcp syn-ack(second handshark) packet

    Saturday, November 9, 2013 3:42 AM
  • Have you tried getting a wfp capture when this occurs? (netsh wfp capture start).  Are there any drop events for the packet you are injecting?

    have you validated that the packet is formatted properly?  checksum are correct etc.


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Sunday, November 10, 2013 4:37 AM
    Moderator
  • problem remains

    here is some info from "netsh wfp capture"

    		<aleConnectedEndpoints numItems="1">
    			<item>
    				<endpointId>66</endpointId>
    				<ipVersion>FWP_IP_VERSION_V4</ipVersion>
    				<localV4Address>192.168.245.133</localV4Address>
    				<remoteV4Address>192.168.245.1</remoteV4Address>
    				<ipProtocol>6</ipProtocol>
    				<localPort>14</localPort>
    				<remotePort>123</remotePort>
    				<localTokenModifiedId>1003</localTokenModifiedId>
    				<mmSaId>0</mmSaId>
    				<qmSaId>0</qmSaId>
    				<ipsecStatus>0 (ERROR_SUCCESS)</ipsecStatus>
    				<flags/>
    				<appId>
    					<data>530079007300740065006d000000</data>
    					<asString>S.y.s.t.e.m...</asString>
    				</appId>
    			</item>
    		</aleConnectedEndpoints>

    and the possibility you mentioned,i dont think so.

    what im doing is respond a syn-ack packet to remote(192.168.245.1). and the packets im pretty sure they are all the same ,since i've wrapped a function to make the packet .

    there is one more thing i need to mention. like i said before, i only happends at the first time for each port(eg:192.168.245.1 connect to 192.168.245.133:14 and  192.168.245.133:15, since the socket routine :connect() will try times, so

    FwpsInjectNetworkSendAsync 

    will be called times too ,let's say 3 time for each port ,so

    FwpsInjectNetworkSendAsync 

    will be called 6 times .the first time for port 14 and the fourth time for port 15. then we will see STATUS_DATA_NOT_ACCEPTED happens only at these two moment. the rest succeed all the time!

    BTW,i would be appreciated if you can tell me how to read the report from netsh wfp capture


    Tuesday, November 12, 2013 9:05 AM
  • Is my assumption that you are doing this from FWPM_LAYER_OUTBOUND_IPPACKET_V4 correct?  Did the SYN reach the stack OK?

    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Wednesday, November 13, 2013 5:51 AM
    Moderator
  • Is my assumption that you are doing this from FWPM_LAYER_OUTBOUND_IPPACKET_V4 correct?  Did the SYN reach the stack OK?

    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    im doing this at inbound_ippacket_v4 layer,and i drop the SYN,so i dont think SYN can reach the tcpip stack
    Wednesday, November 13, 2013 6:34 PM
  • To further help you with this, I will need:

    1. a memory dump
    2. a network trace
       NetSh Trace Start scenario=InternetClient
       NetSh WFP Capture Start
       Repro the issue
       NetSh WFP Capture Stop
       NetSh Trace Stop

    You can email the data to DHarper @AT@ Microsoft .DOT. com


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Thursday, November 14, 2013 7:47 PM
    Moderator
  • To further help you with this, I will need:

    1. a memory dump
    2. a network trace
       NetSh Trace Start scenario=InternetClient
       NetSh WFP Capture Start
       Repro the issue
       NetSh WFP Capture Stop
       NetSh Trace Stop

    You can email the data to DHarper @AT@ Microsoft .DOT. com


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    data sent

    BTW,i set a breakpoint on the Status member ,then i found it return data_not_accept here:

    8867a259 8b4510          mov     eax,dword ptr [ebp+10h]
    8867a25c ff7010          push    dword ptr [eax+10h]
    8867a25f e8c295ffff      call    tcpip!IppInspectLocalDatagramsOut (88673826)
    8867a264 83f801          cmp     eax,1
    8867a267 7c57            jl      tcpip!IppSendDatagramsCommon+0x604 (8867a2c0)
    8867a269 7405            je      tcpip!IppSendDatagramsCommon+0x5b4 (8867a270)
    8867a26b 83f802          cmp     eax,2
    8867a26e 7507            jne     tcpip!IppSendDatagramsCommon+0x5bb (8867a277)
    8867a270 c745f81b0200c0  mov     dword ptr [ebp-8],0C000021Bh
    8867a277 8b45f8          mov     eax,dword ptr [ebp-8]
    8867a27a 8b4df4          mov     ecx,dword ptr [ebp-0Ch]
    8867a27d 8b354c136e88    mov     esi,dword ptr [tcpip!_imp__ExFreePoolWithTag (886e134c)]
    8867a283 89414c          mov     dword ptr [ecx+4Ch],eax //break here
    8867a286 8b432c          mov     eax,dword ptr [ebx+2Ch] ds:0023:866b64b8=871b4818
    8867a289 85c0            test    eax,eax
    8867a28b 7409            je      tcpip!IppSendDatagramsCommon+0x5da (8867a296)


    one more thing:

    before calling FwpsInjectNetworkSendAsync  I call FwpsConstructIpHeaderForTransportPacket0 to help caculate both ip and tcp checksum




    Friday, November 15, 2013 8:43 AM
  • any updates?
    Tuesday, November 19, 2013 8:37 AM
  • I have received the files, and will try to update later this week.

    Thanks,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Tuesday, November 19, 2013 5:55 PM
    Moderator
  • updates:

    there is a good-bad news

    looks like i use the transport inject handle as a net work inject handle!!

    after i fix it , returning STATUS_DATA_NOT_ACCEPTED never occurs. sorry for my mistake.


    BUT,why the second time it succeed ?
    Tuesday, November 26, 2013 8:44 AM