I have a Windows XP intermediate filter driver which redirects host’s HTTP traffic to a local proxy application (user mode) as follows:
HTTP client <==> IM driver <==> proxy <==> IM driver <==> [Cisco VPN] <==> HTTP server
When user performs HTTP download of a large file the proxy’s client side socket overflows very soon. In this case the proxy is designed to stop reading from its server side socket until the client side becomes writable again. And the latter never happens until TCP reaches data timeout. The problem seems to exist only when data flows through Cisco VPN which uses its own IM failover driver (deterministic network enhancer).
There is no error reported when the problem occurs. I installed the checked build of Windows XP SP3 to try to figure out what’s wrong. My driver was also defined as “failover”, but the checked “netcfg” was throwing assert messages complaining on two drivers of the same class so I changed mine to “loadbalance”. There are no more complaint but the main problem is still there. I really have no more ideas on how to find what’s wrong.
Do you have any ideas what to look for or how to debug this?
Does the problem occurs without your IM driver? What about if you disable TCP/IP Offloading for that adapter? Or if your IM driver is in pass-through mode?
Hi Cristi,
The problem does not exist without my IM driver, there is no proxy application in this case as well. The problem also does not exist in case my IM driver is in pass-through mode.
Regarding TCP/IP offloading. I filter OID_TCP_TASK_OFFLOAD in MiniportQueryInformation by replying NDIS_STATUS_NOT_SUPPORTED. Is it enough for disabling it?
I think that the problem might be somewhere in this part:
HTTP client <==> IM driver <==> proxy
as packets sent by the client are indicated back to the protocol by the IM driver in order to get to the proxy and vice versa.
The driver intercepts packets coming from the protocol and from the network. If a packet coming from protocol is HTTP and not originated from the proxy it’s indicated back to the protocol so that the proxy can process it and possibly send further to the remote server. If a packet coming from protocol is originated from the proxy it can be indicated back to the protocol for the client or can be forwarded down to the network to reach the remote server. Packets coming from the network related to active HTTP connections are forwarded to the protocol to be processes by the proxy.
WPF is not relevant for Windows XP and unfortunately it’s too late for TDI…
I now have some more information about this problem.
As I mentioned the problem happens when the proxy application can not send anymore data to the client because the client side socket buffers are overflown. In this case proxy inserts its client side socket handle into the select()'s writefds socket set and waits until it becomes writable and it never does! This does not happen without Cisco VPN.
The question is what happens in NDIS (if something happens) and/or TCP when socket buffers overflow?
In the driver log I can see that at some point proxy sends a TCP packet with data for the client down the NDIS stack, the driver redirects it to the client by changing addresses and indicates it back to the protocol. The client sends TCP ACK which is redirected by the driver to the proxy (in the same way) and it looks like as if this ACK never reached proxy’s client side socket.
I modified the driver to indicate packets from the “send path” in separate context by use of work items. It helped in a way that it’s now considerably harder to reproduce this problem but it still happens.
Do you have any on idea how to figure out what’s going wrong there?