Freezed download via Wanproxy

Wed Mar 14 21:43:24 PDT 2018

Hi Juli,

I have managed to install couple FreeBSD 11 RELEASE VMs (that was
really tricky, but setting up second one was finally easier than
first), built the Wanproxy on them and executed the same experiment.
I have tried few various combinations: all locally, on the same
Linux/FreeBSD machine, and client on the one Linux/FreeBSD machine
with server on the different Linux/FreeBSD machine.
And the result was the same in all cases - when "server" Wanproxy goes
down, "client" Wanproxy does not disconnect its client. So I think
there must be major issue the Wanproxy logic.
I still did not review source code deeply yet, but can you please
confirm, do you really think that current implementation should
propagate connection state correctly inside "client" Wanproxy?

Also I have got Wanproxy crash on FreeBSD, when attempted to specify
server VM name in the client wanproxy config.
I have put following into my client.conf:

create peer peer0
set peer0.family IP
set peer0.host "wptest1"
set peer0.port "3301"
activate peer0

This have given me following error (and crash right after it):
1521079851.327281 [/socket/address] ERR: bool
socket_address::operator()(int, int, int, const string&): Could not
look up [wptest1]:3301: hostname nor servname provided, or not known
1521079851.327354 [/socket/handle] ERR: static SocketHandle*
SocketHandle::create(SocketAddressFamily, SocketType, const string&,
const string&): Invalid hint: [wptest1]:3301
./client.sh: line 1: 13501 Segmentation fault (core dumped) ./wanproxy
-c client.conf

Note that on Linux that worked pretty good.
I have had name resolution configured through WINS (Samba), i.e. have
running Samba with valid config, and have wins added to
/etc/nsswitch.conf:

hosts: files wins dns

Note that ping has reached that host successfully:

$ ping wptest1
PING wptest1 (192.168.150.11): 56 data bytes
64 bytes from 192.168.150.11: icmp_seq=0 ttl=64 time=0.266 ms
64 bytes from 192.168.150.11: icmp_seq=1 ttl=64 time=0.234 ms
64 bytes from 192.168.150.11: icmp_seq=2 ttl=64 time=0.381 ms
64 bytes from 192.168.150.11: icmp_seq=3 ttl=64 time=0.382 ms
64 bytes from 192.168.150.11: icmp_seq=4 ttl=64 time=0.269 ms
^C
--- wptest1 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.234/0.306/0.382/0.063 ms

But wanproxy crashed.
I had to specify IP address (192.168.150.11) instead of name(wptest1)
to mitigate this.
But it works on Linux with no matter there is IP address or host name.

WBW, Ivan.

2018-03-07 5:01 GMT+02:00 Juli Mallett <juli at clockworksquid.com>:
> Hi Ivan,
>
> I don't know the Linux TCP/IP stack, unfortunately, so I can't be any help
> there.  In your case, I think you might want to consider adding, or having
> someone add, a simple heartbeat mechanism to the xcodec protocol in
> WANProxy.
>
> Thanks,
> Juli.
>
> On Tue, Mar 6, 2018 at 6:15 PM, Ivan Pizhenko <ivan.pizhenko at gmail.com>
> wrote:
>>
>> Hi Juli,
>>
>> Thanks for replying to my email.
>>
>> I am using Linux. I have set up VirtualBox VM with Xubuntu 16.04 LTS
>> with latest HWE kernel 4.13 and all latest updates. I have not tuned
>> any OS options related to networking and TCP/IP protocol. I am not
>> using libuinet. I am not targeting FreeBSD, I need to have it working
>> on Linux, primarily on Ubuntu Server.
>>
>> So I also was expecting that connection should be reset after some
>> reasonable timeout, but that didn't happen (or I have waited for too
>> short time??? I remember it was like at least 10 minutes). So present
>> mechanism seems to don't work. Thanks, heartbeat is interesting idea,
>> but probably there is something we can do via TCP connection settings
>> that we did not do yet? I am not big specialist in TCP protocol
>> settings, but I suppose you must be more aware in this area, so I am
>> asking about this, probably you can recommend something else. If
>> nothing more can be done, then sure, I will need to implement
>> heartbeat.
>>
>> Ivan.
>>
>>
>> 2018-03-06 3:48 GMT+02:00 Juli Mallett <juli at clockworksquid.com>:
>> > Hi Ivan,
>> >
>> > WANProxy should pass along state when a stream is closed from end to
>> > end,
>> > not perfectly, but your connection should be properly reset at some
>> > point
>> > from the server going away.  There isn't anything that can be done in a
>> > protocol-neutral way that exceeds that, but that should be good enough
>> > for
>> > most uses.  Of course there are things that can disrupt the TCP state
>> > machine, or settings on a system can mean that connections aren't timed
>> > out
>> > when they should be.
>> >
>> > Are you using libuinet, FreeBSD, Linux, or something else for the TCP/IP
>> > stack?
>> >
>> > An easy change would be to add a heartbeat on all active sessions with
>> > WANProxy to actively probe for disconnected peers, but I'm not sure I'd
>> > encourage that.  If you think that would be helpful to you, let me know.
>> >
>> > Thanks,
>> > Juli.
>> >
>> > On Sat, Feb 24, 2018 at 1:09 AM, Ivan Pizhenko <ivan.pizhenko at gmail.com>
>> > wrote:
>> >>
>> >> 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 wanproxy.org, 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 lists.wanproxy.org
>> >> http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org
>> >
>> >
>
>