locked
Is it possible to force SO_KEEPALIVE for specific TCP connections from within WFP callout driver? RRS feed

  • Question

  • Hello,

    I want to modify the SO_KEEPALIVE socket option for certain TCP connections, so that 'idle' connections are not terminated by the perimeter firewall.
    Unfortunately, I cannot set the SO_KEEPALIVE option in the application code (the socket is created by HTTP.sys), and also cannot modify the perimeter firewall settings.
    The TCP connection is 'idle' because of a single long-running HTTP request (the issue is completely unrelated to HTTP 1.1 Keep-Alive feature).

    Is it possible to set the SO_KEEPALIVE option from a WFP callout driver?
    Is it even possible to obtain the WSK_SOCKET pointer associated with a TCP connection?

    I don't want to inject the 'keep-alive' packets manually - it will very likely cause bugs, it will reduce performance and it won't work if TCP Chimney is enabled.
    And, of course, a LSP won't work either with HTTP.SYS.

    Thank you.

    Wednesday, August 24, 2011 3:48 PM

Answers

  • Currently this is not supported by WFP.  You could go the route of injecting your own keep-alive packets, but it would be difficult as you need to make sure the sequence numbers remain consistent between host and server.

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, August 24, 2011 8:42 PM
    Moderator

All replies

  • Currently this is not supported by WFP.  You could go the route of injecting your own keep-alive packets, but it would be difficult as you need to make sure the sequence numbers remain consistent between host and server.

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, August 24, 2011 8:42 PM
    Moderator
  • Thank you very much for quick reply.

    This particular scenario is something that was actually better supported by LSPs - too bad they don't work here :)

    The problem with packet injection is that I have to process each packet (impacting the performance), and also keep quite a lot of timers/etc. (huge opportunity for bugs).
    If I have to touch each packet anyway, I might as well just configure HTTP.SYS to listen on an alternate port, and then implement a simple kernel-mode TCP connection proxy (similar to netsh interface portproxy add v4tov4 listenport=80 connectaddress=<local_ip> connectport=81).
    But then I lose information about client IP (unless I parse HTTP stream and inject custom headers, which is a hassle especially with HTTP Keep-Alive, chunked transfer mode, and SSL...).

    What happens if I use NmrRegisterProvider with NpiId = NPI_WSK_INTERFACE_ID and ModuleId = NPI_MS_IPV4_MODULEID ?
    Couldn't I just hook kernel-mode WinSock dispatch table this way, similar to old-school LSP approach?

    Thank you.

    [Edit: NPI_MS_IPV4_MODULEID seems to be completely wrong - it's some lower-level, undocumented NPI...]
    Wednesday, August 24, 2011 9:38 PM