locked
Pending Endpoint Closure Classify RRS feed

  • Question

  • I am working with the WFP using out of band processing at the stream layer for both incoming and outgoing traffic. The problem I am having is when inbound or outbound traffic is queued for processing I have seen the flow being closed before I have been able to reinject the out of band traffic into the stream. I have added a callout at the ENDPOINT_CLOSURE layer and have been able to use the PendClassify but it appears that even if the PendClassify reurns STATUS_SUCCESS the closure is not pended. I am sure it is something I am doing wrong and wondered if there are any examples of how to implement this properly. I am not sure if it has to do with the way I have defined the filter, added the callback or if I am not properly returning the correct values for classifyOut from the Endpoint_closure callback. Any help is appreciated.

    Joe Field

    Friday, February 21, 2014 2:32 PM

Answers

  • ENDPOINT_CLOSURE doesn't prevent the FINs from going out. It prevents the endpoint from going away (no longer able to send / receive). If you want the FIN to be held up, then you need to handle that in your STREAM callout (it gets indicated as a flag in STREAM).

    Hope this helps,


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

    • Marked as answer by JField Tuesday, March 18, 2014 10:59 PM
    Tuesday, March 18, 2014 9:05 PM
    Moderator

All replies

  • The upcoming update to the WFPSampler (which should be available sometime in April) has a sample for this scenario.

    How are you currently implementing this? 

    In the endpoint closure classifyFn, you need to call FwpsAcquireClassifyHandle and then FwpsPendClassify.  You will need the classifyHandle and classifyOut information for later, so you need a mechanism to associate those with the flow you are pending.  The classifyFn will exit.

    In the flowDeleteFn of your stream callout you would call FwpsCompleteClassify and finally FwpsReleaseClassifyHandle.

    Hope this helps,


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

    Friday, February 21, 2014 6:13 PM
    Moderator
  • Thanks Dusty,


    Joe Field

    Friday, February 21, 2014 6:32 PM
  • I am implementing as you described except I am completing the classify in the out of band injection completion function. I'll try at the flow delete.

    Thank You


    Joe Field

    Friday, February 21, 2014 6:33 PM
  • I tried putting the FwpsCompleteClassify in the FlowDeletion function and it appears the FlowDeletion call is not being made. Does FlowDeletion get called after the  FwpsCompleteClassify for the endpoint closure?

    Thanks,

    Joe

     

    Joe Field

    Friday, February 21, 2014 8:44 PM
  • FlowDeleteFn is called when the flowState goes away. For TCP this usually means the 4-way FIN handshake has completed or a RST was received. For non-TCP, the flow state is cleaned up after ~ 60 seconds of no usage.

    If you did not associate context with the flow then it will not get invoked.  In this case, you would need to do as you are doing and sit in the injection's completionFn, and figure out if this invocation is for the last of the flow being injected (i.e. the FIN), and call FwpmCompleteClassify and FwpsReleaseClassifyHandle.

    Hope this helps,


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

    Friday, February 21, 2014 9:41 PM
    Moderator
  • Dusty,

    I was doing what you suggested. I keep a count of reinjections pending for a given flow. If I receive an endpoint closure callback before all the reinjections have completed I copy and save the classifyHandle and classifyOut in a structure associated with the flow. I then pend the endpoint closure. I also set a flag in that structure to indicate that when the last reinjection occurs for the flow the FwpmCompleteClassify and FwpsReleaseClassifyHandle to be called with the saved classifyHandle and classifyOut. What I'm seeing in my debug traces is that everything proceeds as I would expect. What I am not expecting is that in a Netmon trace I am seeing the FIN being sent from the server sending the data and a FIN acknowledgement being returned from the client ( where my filter is located ) before the FwpmCompleteClassify for the pended endpoint closure is being called. I am probably erroneously assuming that pending the endpoint closure is blocking that FIN from the server. 

    Thank You,

    Joe


    Joe Field

    Friday, February 21, 2014 10:19 PM
  • From my read, you are essentially losing the second half of the FIN handshake correct? You say you are associating context with the flow.  If this is the case, then the FlowDeleteFn should be invoked. It sounds like something is holding up the final FIN.

    Are you seeing the outbound FIN in the stream? (FWPS_STREAM_FLAG_SEND_DISCONNECT has been set)

    Thanks,


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

    Friday, February 21, 2014 11:44 PM
    Moderator
  • Hi Dusty,
     I don't think I was clear about the problem. In fact I probably don't correctly understand what is happening. The trace below contains a combination of a NetMon capture and the Traceview out put from the callouts in the driver I am working on. This particular scenario is for an FTP LIST command. When the Endpoint Closure callout is called and pended I was expecting the FIN from the server to be pended to allow reinjection of the imcoming data that was queued up for out of band processing. Instead, the call to PEND the closure returns success and before the queued data can be reinjected the client sends a FIN back to the server. The queued data is still available and is reinjected for the client FTP process but the data is not handled by that process. My only guess as to what is happening is that the FTP process receives the FIN from the server, closes it connection and does not look for the incoming data that is later reinjected. Can you provide any insight? I am probably making too many uninformed assumptions about how this works.

    Thank You,
    Joe


    09:48:58.1946157 32 filezilla.exe 192.168.1.60 192.168.1.10 FTP FTP:Request from Port 52938,'PORT 192,168,1,60,206,203'
    09:48:58.1950623 33 filezilla.exe 192.168.1.10 192.168.1.60 FTP FTP:Response to Port 52938, '200  PORT command successful.'
    09:48:58.2412550 34 filezilla.exe 192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...., SrcPort=52938, DstPort=FTP control(21)
    09:48:58.4085517 35 filezilla.exe 192.168.1.60 192.168.1.10 FTP FTP:Request from Port 52938, 'LIST'
    09:48:58.4090272 36 filezilla.exe 192.168.1.10 192.168.1.60 FTP FTP:Response to Port 52938, '150  Opening BINARY mode data connection for /bin/ls.'
    09:48:58.4092537 37   192.168.1.10 192.168.1.60 TCP TCP:Flags=......S., SrcPort=FTP data(20), DstPort=52939
    09:48:58.4093658 38   192.168.1.60 192.168.1.10 TCP TCP:Flags=...A..S., SrcPort=52939, DstPort=FTP data(20)
    09:48:58.4097615 39   192.168.1.10 192.168.1.60 TCP TCP:Flags=...A...., SrcPort=FTP data(20), DstPort=52939
    09:48:58.4101032 40   192.168.1.10 192.168.1.60 FTP FTP:Data Transfer To Client,DstPort = 52939,size = 695 bytes

    ////////////TRACE FROM Stream Callout that queues incoming data on FTP data port occurs here
    ///////////////////////////////EchoOobQueueUpIncomingData Flags= 0x11 FlowHandle=1C8C Size=695 - 02-06-12 01:46PM   <DIR>    AdminScripts.....
    09:48:58.4101032 41   192.168.1.10 192.168.1.60 TCP TCP:Flags=...A...F, SrcPort=FTP data(20), DstPort=52939
    ////////////TRACE FROM Endpoint Closure Callout FTP data port occurs here. The FIN above is sent from the FTP server when data send is complete.

    ////////////////////////////// EchoCoALEEndClosureCalloutV4 PENDING SENT status = 0x0   ////////////The PendClassify does return status SUCCESS

    09:48:58.4102100 42   192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...., SrcPort=52939, DstPort=FTP data(20)

    ///////////At this point it appears that a FIN is sent from the client to the server. I was expecting this to not be sent since Endpoint closure was pended.
     
    09:48:58.4108284 43   192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...F, SrcPort=52939, DstPort=FTP data(20)
    09:48:58.4112343 44   192.168.1.10 192.168.1.60 TCP TCP:Flags=...A...., SrcPort=FTP data(20), DstPort=52939
    09:48:58.4711508 45 filezilla.exe 192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...., SrcPort=52938, DstPort=FTP control(21)
    09:48:58.4718129 46 filezilla.exe 192.168.1.10 192.168.1.60 FTP FTP:Response to Port 52938, '226  Transfer complete.'
    09:48:58.5224492 47 filezilla.exe 192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...., SrcPort=52938, DstPort=FTP control(21)
    09:49:01.0521366 48 filezilla.exe 192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...F, SrcPort=52938, DstPort=FTP control(21)
    09:49:01.0526467 49 filezilla.exe 192.168.1.10 192.168.1.60 TCP TCP:Flags=...A...., SrcPort=FTP control(21), DstPort=52938
    09:49:01.0526467 50 filezilla.exe 192.168.1.10 192.168.1.60 TCP TCP:Flags=...A...F, SrcPort=FTP control(21), DstPort=52938
    09:49:01.0527516 51 filezilla.exe 192.168.1.60 192.168.1.10 TCP TCP:Flags=...A...., SrcPort=52938, DstPort=FTP control(21)


    Joe Field

    Sunday, February 23, 2014 9:00 PM
  • Dusty,
     Do you have any insight that can help me with this issue?
    Thank You,
    Joe Field


    Joe Field

    Wednesday, February 26, 2014 4:04 PM
  • ENDPOINT_CLOSURE doesn't prevent the FINs from going out. It prevents the endpoint from going away (no longer able to send / receive). If you want the FIN to be held up, then you need to handle that in your STREAM callout (it gets indicated as a flag in STREAM).

    Hope this helps,


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

    • Marked as answer by JField Tuesday, March 18, 2014 10:59 PM
    Tuesday, March 18, 2014 9:05 PM
    Moderator