locked
Notification for non-established TCP connection closure RRS feed

  • Question

  • Lets assume that a process tries to connect to a non-existing remote endpoint. In this case the  FWPS_LAYER_ALE_AUTH_CONNECT_V4/6 classify callback gets invoked, but the flow never gets established, i.e. the FWPS_LAYER_ALE_FLOW_ESTABLISHED_V4/6 classify callbacks are not invoked.

    My first naive assumption was that in this case, whenever the TCP/IP stack tears down its internal connection control block it is going to call the callouts registered at FWPS_LAYER_ALE_AUTH_CONNECT_V4/6_DISCARD. Unfortunately based on my experience this is not the case. I verified that the discard callbacks are invoked when a connection is blocked by my callout, hence my question: what do I need to do in order for my callout to get notified whenever TCP times out and gives out on a connection?
    Thursday, April 9, 2009 10:36 PM

Answers

  • For Win7, you should get a ALE_ENDPOINT_CLOSURE classify for that TCB if you register under the new layer.

    For Vista there is no such inspection point. One workarond would be startint a timer and assume the connection failed to establish after 21 seconds.

    Hope this helps,
    Biao.W.
    • Marked as answer by svassilev Tuesday, April 14, 2009 4:39 PM
    Tuesday, April 14, 2009 6:40 AM

All replies

  • For Win7, you should get a ALE_ENDPOINT_CLOSURE classify for that TCB if you register under the new layer.

    For Vista there is no such inspection point. One workarond would be startint a timer and assume the connection failed to establish after 21 seconds.

    Hope this helps,
    Biao.W.
    • Marked as answer by svassilev Tuesday, April 14, 2009 4:39 PM
    Tuesday, April 14, 2009 6:40 AM
  • For Win7, you should get a ALE_ENDPOINT_CLOSURE classify for that TCB if you register under the new layer.
    I have noticed, strange thing (bug?) on my Windows 7 Beta x64 (v6.1.7100), when I use FWPM_LAYER_ALE_ENDPOINT_CLOSURE_V4:

    For TCP connections everything is ok: my callout classyfy function reports about connection closure:
    [LOG] Detected closed connection: Proto: 6; Local: 192.168.113.22:49192; Remote: 172.16.0.57:139; layerData: 0; flowContext: 0

    For UDP 'connections' my classify function always get some garbage in inFixedValues field:
    [LOG] Detected closed connection: Proto: 17; Local: 0.0.0.9:59372; Remote: 3.115.138.16:35344; layerData: 0; flowContext: 0

    Why can it be so? Is this some well-known feature or a bug?
    Friday, July 10, 2009 12:46 PM
  • I have not been able to repro this in house.  Can you please clarify a few items?

    1) Is this socket explicitly bound (bind() was specifically called) or implicitly bound (a sendto() or connect() was called without calling bind())
    2) How are you parsing out the local address / port and remote address / port?  Are you basing your information on  the type indicatied in the FWP_VALUE0?
    3) Have you verified other fields in the inFixedValues (such as APP_ID)?

    For UDP (being a connectionless protocol) it is possible that the remote IP address is never indicated, in which case the type will be FWP_EMPTY.  If it's an implicitly bound socket, then it is possible that the local address is not indicated, again in which case the type will be FWP_EMPTY.




    Dusty Harper [MSFT]
    Thursday, July 30, 2009 8:44 PM
    Moderator