Freezed download via Wanproxy

Ivan Pizhenko ivan.pizhenko at
Wed Mar 7 23:06:27 PST 2018

Thank, Eleizer.

Here's what I've got:

$ sysctl -a 2>/dev/null | egrep "tw|fin|tcp_keepalive_time"
net.ipv4.tcp_fin_timeout = 60
net.ipv4.tcp_keepalive_time = 7200
net.ipv4.tcp_max_tw_buckets = 16384
net.ipv4.tcp_tw_reuse = 0

I believe these are just defaults. If we assume Wanproxy handles the
thing corrctly (I didn't check the code yet so deeply),  then what
else you think can be wrong?
Again, this is very simple test conducted completely locally, i.e. I
am running 2 Wanproxies and target Apache HTTP server and finally wget
on the same host.

2018-03-07 19:58 GMT+02:00 Eliezer Croitoru <eliezer at>:
> Thanks Ivan,
> I now clearly understand what you are trying to achieve and what I was wrong about.
> From the example description it wasn't clear if it's should only be a gateway or if your requirement is for it to work transparently or not.
> Go or C or C++ whatever works for you is good.
> (The github repo is basically a code example which I wrote for someone in china and the README was.. via VOIP..)
> Now I do understand the issue but something is missing for me.
> I admit that I took as granted what WanProxy is based on an assumption that I was wrong about.
> So I re-read your initial post and then looked at the example at:
> This is where I understood I managed to mix two different solutions I have seen in the past.
> WanProxy is a simple TCP proxy which can also act in a SOCKS proxy mode.
> I was wrongly under the impression that WanProxy is a full stack TCP transparent proxy which designed to optimize any TCP connection if possible..
> I have not seen the code yet so I assumed that a simple rule of thumb would be that the socket would be closed automatically after the OS will complete the FIN-WAIT+TIME-WAIT+CLOSE cycle as in:
> I believe that to understand what happens on your local machine when it happens you should examine the sockets  status\state using the command:
> ss -tn
> with or without a heartbeat\keepalive in the connection the OS should close the connection eventually and the defaults are 60/120 seconds.
> The next command:
> sysctl -a 2>/dev/null |egrep "tw|fin|tcp_keepalive_time"
> should show you what the OS parameters are that might affect this issue.
> All The Bests,
> Eliezer
> ----
> Eliezer Croitoru
> Linux System Administrator
> Mobile: +972-5-28704261
> Email: eliezer at
> -----Original Message-----
> From: Ivan Pizhenko [mailto:ivan.pizhenko at]
> Sent: Wednesday, March 7, 2018 11:33
> To: Eliezer Croitoru <eliezer at>
> Cc: wanproxy at
> Subject: Re: Freezed download via Wanproxy
> Hi Elizer,
> What I finally want to achieve is to optimize bandwidth, and do it regardless to application level protocol, i.e. solution must work just for any TCP traffic.
> Wanproxy is primarily intended for that, that's why I choose it. But I need to make sure it is reliable.
> I am not sure what exactly your library does, there's even no any README in your github repo.
> Also I am developing in C and C++, not in go. So my impression is that your library is unlikely useful for me.
> WBW, Ivan.
> 2018-03-07 8:03 GMT+02:00 Eliezer Croitoru <eliezer at>:
>> Hey Ivan,
>> It's not clear to me what you are testing or trying to test.
>> There are couple levels of optimizations that you might want to achieve but you need to clear things for yourself first.
>> If you need a full TCP\IP stack proxy then it depends on the network structure and also the setup is yet to be clear to me.
>> I have a list of proxies at a post I wrote and update from time to time:
>> realistic/
>> but... if you need to access a remote network via a proxy it's one issue.
>> If you want to optimize the connection by utilizing the proxy bandwidth compared to the client it's another.
>> Give us a clear "shot" or "scenario" which I can reproduce locally.
>> I need to know what to try and setup so I would be able to try and grasp the issue.
>> I wrote a tiny library and couple examples at:
>> which is being used in couple a very big networks and seems to give them what they need.
>> All The Bests,
>> Eliezer
>> ----
>> Eliezer Croitoru
>> Linux System Administrator
>> Mobile: +972-5-28704261
>> Email: eliezer at
>> -----Original Message-----
>> From: Ivan Pizhenko [mailto:ivan.pizhenko at]
>> Sent: Wednesday, March 7, 2018 04:03
>> To: Eliezer Croitoru <eliezer at>
>> Cc: wanproxy at
>> Subject: Re: Freezed download via Wanproxy
>> Hi Eliezer,
>> I am trying to achieve this test passing for Wanproxy. I am
>> insterested in doing this exactly with Wanproxy, not any other
>> software.
>> In this case, HTTP is used as sample, the thing should work regardless
>> to any application-level protocol.
>> It must work on the TCP/IP connection level.
>> WBR, Ivan.
>> 2018-03-06 3:33 GMT+02:00 Eliezer Croitoru <eliezer at>:
>>> Hey Ivan,
>>> Can you give more details on what you want to achieve  eventually?
>>> Are you trying to achieve a specific goal from one of the options
>>> WanProxy offers?
>>> Depends on the relevant protocol you will use wanproxy for like http
>>> you might have another more suitable solution ready to use.
>>> There are couple other ways\proxies that offers TCP connections
>>> optimization but it's very important to be very specific on your
>>> goals since a "catch all" solution is not going to help you to resolve a specific issue.
>>> Let me know if I might be able to try and help you.
>>> Eliezer
>>> * if you have tried other ideas then WanProxy let me know which
>>> ----
>>> Eliezer Croitoru
>>> Linux System Administrator
>>> Mobile: +972-5-28704261
>>> Email: eliezer at
>>> -----Original Message-----
>>> From: wanproxy [mailto:wanproxy-bounces at] On Behalf
>>> Of Ivan Pizhenko
>>> Sent: Saturday, February 24, 2018 11:09
>>> To: wanproxy at
>>> Subject: Freezed download via Wanproxy
>>> Hi,
>>> I am making some tests with Wanproxy to understand how much it is
>>> stable and reliable. I am using latest Wanproxy code from Github and
>>> work on Ubuntu 16.04 LTS with kernel 4.13 and all latest updates.
>>> I have conducted following simple test:
>>> I have installed locally Apache 2 HTTP Server and put some large file
>>> into the document root. Then I have configured, also locally, "client"
>>> and "server" Wanproxy similar to how it is described in examples
>>> section on, but without ssh tunnel between them, to
>>> proxy Apaches's HTTP port. Then I have used wget to download that
>>> large file through "client" Wanproxy. It worked fine but slower than
>>> direct download from Apache. Then I have tried to do the same thing
>>> but  I have shut down "server" Wanproxy somewhere in the middle of download.
>>> The download has freezed, the were no further progress. When I have
>>> restarted "server" Wanproxy, the download did not resume. When I shut
>>> down client Wanproxy, wget showed error like "connection refused" and
>>> exited.
>>> I would expect that when "server" Wanproxy went down, "client" one
>>> would disconnect clients connected to it to indicate that upstream
>>> link is broken, if not immediately, then after some reasonable
>>> timeout. Is there a way to achieve something like this with Wanproxy?
>>> If not, what changes to Wanproxy are needed to enable such
>>> functionality?
>>> Ivan.
>>> _______________________________________________
>>> wanproxy mailing list
>>> wanproxy at

More information about the wanproxy mailing list