none
How to get list of exist stream flow? RRS feed

  • Question

  • We need to make our product start work just after installation, without reboot on VISTA.

    When our callout start running, there maybe already some exist stream flow.

    We need to examine all these streams and disconnect them according to rule.

    How can I get the current streams list?
    Friday, September 28, 2007 7:08 PM

Answers

  • I think you can also use iphlpapi to abort a TCP connection. checkout the SetTcpEntry() function.

     

    Yes I agree life would be simpler if WFP were to invoke STREAM callouts even for pre-existing flows and you simply return FWPS_STREAM_ACTION_DROP_CONNECTION.

     

    Thanks for the feedback -- We are monitoring feedbacks like yours for future improvements.

     

    Biao.W.

     

     

    Friday, September 28, 2007 11:34 PM

All replies

  • WFP currently does not classify data segments of an pre-existing TCP flow to a freshly added STREAM layer callout.

     

    TRANSPORT (TL) layer callouts, however, will start to set TCP packets as soon as being added.

     

    Does your product modify stream data? If not, registering at TL and inspect TCP on a per packet basis may meet your need. However, performing TCP data modification at TL will be difficult because of the seq/ack# adjustments you would also need to perform.

     

    Biao.W.

    Friday, September 28, 2007 10:09 PM
  • Does that means if we want to kill the pre-existing connections, we need to construct a RST tcp packet and inject it, right? That's quite more complicated than the old TDI filter, in which we just build and send a TDI_DISCONNECT IRP

    Will it be added into future version of WFP to enable inspecting pre-existing stream and disconnect it?

     

    Friday, September 28, 2007 10:19 PM
  • I think you can also use iphlpapi to abort a TCP connection. checkout the SetTcpEntry() function.

     

    Yes I agree life would be simpler if WFP were to invoke STREAM callouts even for pre-existing flows and you simply return FWPS_STREAM_ACTION_DROP_CONNECTION.

     

    Thanks for the feedback -- We are monitoring feedbacks like yours for future improvements.

     

    Biao.W.

     

     

    Friday, September 28, 2007 11:34 PM
  • I noticed that my callout gets invoked at FWPM_LAYER_ALE_AUTH_CONNECT_V4/6 with the re-authorize flag set for all the pre-existing connections. Isn't blocking these connect requests going to result in dropped connections? If so this may rsolve the described above problem with the downside that it is very intrusive approach.
    Tuesday, October 16, 2007 5:27 PM
  • That's true, but you were talking about STREAM layer callouts, weren't you?

    Tuesday, October 16, 2007 6:29 PM
  • Not certain I understand.

    What I was saying is that there are provisions to block re-authorize connect requests right after a callout is installed. Now ... if blocking the re-authorize requests is going to result in dropping all the pre-existing connections, then one would think that as a result the flows associated with these connections should be deleted as well, hence there is a way to start monitoring all the stream layer data right after a callout is installed w/o having to re-boot the system.

    Or I can re-state my question in a simpler manner: is blocking re-authorized (pre-existing) connection at the ale_connect layer going to result in deletion of the flows associated with these connections?

    The downside of this approach, as I already mentioned, is that the callout will disturb all the existing traffic, which is rather intrusive and highly undesirable, especially in server environments.
    Tuesday, October 16, 2007 6:52 PM
  • In Vista RTM, BLOCK from re-authorize at ALE_AUTH_CONNECT/RECV_ACCEPT would result in WFP discarding packets belonging to that flow until RST happens w/o furthur classifies. In WS08/SP1 some of the behaviors are changing to facilitate inspection in a weak-host (i.e. local forwardking) environments. I can update the forum once they are finalized.

     

    One benifit of STREAM layer is that ack/seq# are automatically adjusted when data are added/removed. From your description, it seems that all you need to do is to inspect existing flows to decide whether to disconnect them or not. For that you could register at TRANSPORT layer. You will need to do a bit more work at this layer -- to ignore the dataless packets (e.g. standalone ACKs), advance past the TCP header if necessary (i.e. inoutbound), and etc; but you could still get to all TCP data segments.

     

    So you could avoid aborting pre-existing connections until you determine they are not acceptable or if data-modification is required.

     

    (With more work, you could maintain enough states at TRANSPORT to modify data and adjust seq/ack# as well )

     

    Hope this helps,

    Biao.W.

    Thursday, October 18, 2007 9:08 PM