<div dir="ltr">Hi Ivan,<div><br></div><div>I've worked on that code pretty extensively in the past, and I'm pretty sure I tested a wide set of circumstances, but it's certainly possible there's some missing edge case.  I'd suggest looking at the code related to XCODEC_PIPE_OP_EOS and XCODEC_PIPE_OP_EOS_ACK.  If I were testing this, and trying to reproduce it, my first step would be to put INFO or DEBUG statements throughout the code, and to watch what happens in as simplified of a test case as possible, to determine the correct behaviour.</div><div><br></div><div>Note that you have to be very slow and methodical in changing these things, as you can easily make a change which will close the connection in your case, but which is wrong in the case where shutdown(2) is being used on a connection which may, in fact, be long-lived.  That's the sort of mistake that people tend to make in working on middleboxes and proxies: overfitting.  In this case, it sounds like you're reproducing a case where the EOS machinery isn't running properly, but without digging into it, it's hard to be sure what's being too conservative, and how to fix it without breaking other things.  If I were reproducing and testing the issue, my expectation would be that it would come out to be a fairly simple fix in most cases, but I've been wrong about that before.</div><div><br></div><div>I'd be shocked if the polling code for kqueue was wrong, and mildly surprised if it were wrong for epoll, given how extremely widely deployed and tested that code is.  Your assessment that it's probably in the XCodec protocol stuff is probably right, and I hope any of this is helpful to you.  It sounds like you're an accomplished programmer working on WANProxy, so I'm sure you'll be able to figure it out.  If you run in verbose (-v) mode, with debugging compiled in, you should see that there's already some debugging statements around these cases.  Where there might be some loss of fidelity would be in how errors, rather than simply ordinary end-of-stream, propagate into the pipe system.  There's a lot of testing and work I've done on related things, mostly using libuinet, that aren't part of the open source version of WANProxy, so if I had to guess about a location for an issue outside of XCodec, that's where I'd think about looking.  Like, the case where Splice::complete is called with an error: the underlying connections should be torn down, but it's possible that's not happening for some reason.</div><div><br></div><div>Again, just be careful: when changing this kind of thing, overfitting is extremely easy to do.  Good luck, and I look forward to hearing what you find!  I wish I had time to take a look and provide either a patch or a more helpful set of suggestions myself.</div><div><br></div><div>Thanks,</div><div>Juli.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Mar 16, 2018 at 4:32 PM, Ivan Pizhenko <span dir="ltr"><<a href="mailto:ivan.pizhenko@gmail.com" target="_blank">ivan.pizhenko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Juli,<br>
<br>
I've started exploring Wanproxy code and found that socket event<br>
polling with epoll(), which I use in Linux, is likely done correctly.<br>
To check this, I've performed another experiement -  I have set<br>
"codec" to None on the both server and client and tiried again.<br>
And it started to work correctly, exactly as I expect - when I kill<br>
"server" Wanproxy, "client" Wanproxy has disconnected its client -<br>
but... without any traffic optimization, which I want Wanproxy to do.<br>
So the issue must be inside XCodec. Can you please help me to identify<br>
it and recommend how to fix?<br>
<span class="HOEnZb"><font color="#888888"><br>
Ivan.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
2018-03-15 6:43 GMT+02:00 Ivan Pizhenko <<a href="mailto:ivan.pizhenko@gmail.com">ivan.pizhenko@gmail.com</a>>:<br>
> Hi Juli,<br>
><br>
> I have managed to install couple FreeBSD 11 RELEASE VMs (that was<br>
> really tricky, but setting up second one was finally easier than<br>
> first), built the Wanproxy on them and executed the same experiment.<br>
> I have tried few various combinations: all locally, on the same<br>
> Linux/FreeBSD machine, and client on the one Linux/FreeBSD machine<br>
> with server on the different Linux/FreeBSD machine.<br>
> And the result was the same in all cases - when "server" Wanproxy goes<br>
> down, "client" Wanproxy does not disconnect its client. So I think<br>
> there must be major issue the Wanproxy logic.<br>
> I still did not review source code deeply yet, but can you please<br>
> confirm, do you really think that current implementation should<br>
> propagate connection state correctly inside "client" Wanproxy?<br>
><br>
> Also I have got Wanproxy crash on FreeBSD, when attempted to specify<br>
> server VM name in the client wanproxy config.<br>
> I have put following into my client.conf:<br>
><br>
> create peer peer0<br>
> set peer0.family IP<br>
> set peer0.host "wptest1"<br>
> set peer0.port "3301"<br>
> activate peer0<br>
><br>
> This have given me following error (and crash right after it):<br>
> 1521079851.327281 [/socket/address] ERR: bool<br>
> socket_address::operator()(<wbr>int, int, int, const string&): Could not<br>
> look up [wptest1]:3301: hostname nor servname provided, or not known<br>
> 1521079851.327354 [/socket/handle] ERR: static SocketHandle*<br>
> SocketHandle::create(<wbr>SocketAddressFamily, SocketType, const string&,<br>
> const string&): Invalid hint: [wptest1]:3301<br>
> ./client.sh: line 1: 13501 Segmentation fault (core dumped) ./wanproxy<br>
> -c client.conf<br>
><br>
> Note that on Linux that worked pretty good.<br>
> I have had name resolution configured through WINS (Samba), i.e. have<br>
> running Samba with valid config, and have wins added to<br>
> /etc/nsswitch.conf:<br>
><br>
> hosts: files wins dns<br>
><br>
> Note that ping has reached that host successfully:<br>
><br>
> $ ping wptest1<br>
> PING wptest1 (192.168.150.11): 56 data bytes<br>
> 64 bytes from <a href="http://192.168.150.11" rel="noreferrer" target="_blank">192.168.150.11</a>: icmp_seq=0 ttl=64 time=0.266 ms<br>
> 64 bytes from <a href="http://192.168.150.11" rel="noreferrer" target="_blank">192.168.150.11</a>: icmp_seq=1 ttl=64 time=0.234 ms<br>
> 64 bytes from <a href="http://192.168.150.11" rel="noreferrer" target="_blank">192.168.150.11</a>: icmp_seq=2 ttl=64 time=0.381 ms<br>
> 64 bytes from <a href="http://192.168.150.11" rel="noreferrer" target="_blank">192.168.150.11</a>: icmp_seq=3 ttl=64 time=0.382 ms<br>
> 64 bytes from <a href="http://192.168.150.11" rel="noreferrer" target="_blank">192.168.150.11</a>: icmp_seq=4 ttl=64 time=0.269 ms<br>
> ^C<br>
> --- wptest1 ping statistics ---<br>
> 5 packets transmitted, 5 packets received, 0.0% packet loss<br>
> round-trip min/avg/max/stddev = 0.234/0.306/0.382/0.063 ms<br>
><br>
> But wanproxy crashed.<br>
> I had to specify IP address (192.168.150.11) instead of name(wptest1)<br>
> to mitigate this.<br>
> But it works on Linux with no matter there is IP address or host name.<br>
><br>
> WBW, Ivan.<br>
><br>
><br>
> 2018-03-07 5:01 GMT+02:00 Juli Mallett <<a href="mailto:juli@clockworksquid.com">juli@clockworksquid.com</a>>:<br>
>> Hi Ivan,<br>
>><br>
>> I don't know the Linux TCP/IP stack, unfortunately, so I can't be any help<br>
>> there.  In your case, I think you might want to consider adding, or having<br>
>> someone add, a simple heartbeat mechanism to the xcodec protocol in<br>
>> WANProxy.<br>
>><br>
>> Thanks,<br>
>> Juli.<br>
>><br>
>> On Tue, Mar 6, 2018 at 6:15 PM, Ivan Pizhenko <<a href="mailto:ivan.pizhenko@gmail.com">ivan.pizhenko@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi Juli,<br>
>>><br>
>>> Thanks for replying to my email.<br>
>>><br>
>>> I am using Linux. I have set up VirtualBox VM with Xubuntu 16.04 LTS<br>
>>> with latest HWE kernel 4.13 and all latest updates. I have not tuned<br>
>>> any OS options related to networking and TCP/IP protocol. I am not<br>
>>> using libuinet. I am not targeting FreeBSD, I need to have it working<br>
>>> on Linux, primarily on Ubuntu Server.<br>
>>><br>
>>> So I also was expecting that connection should be reset after some<br>
>>> reasonable timeout, but that didn't happen (or I have waited for too<br>
>>> short time??? I remember it was like at least 10 minutes). So present<br>
>>> mechanism seems to don't work. Thanks, heartbeat is interesting idea,<br>
>>> but probably there is something we can do via TCP connection settings<br>
>>> that we did not do yet? I am not big specialist in TCP protocol<br>
>>> settings, but I suppose you must be more aware in this area, so I am<br>
>>> asking about this, probably you can recommend something else. If<br>
>>> nothing more can be done, then sure, I will need to implement<br>
>>> heartbeat.<br>
>>><br>
>>> Ivan.<br>
>>><br>
>>><br>
>>> 2018-03-06 3:48 GMT+02:00 Juli Mallett <<a href="mailto:juli@clockworksquid.com">juli@clockworksquid.com</a>>:<br>
>>> > Hi Ivan,<br>
>>> ><br>
>>> > WANProxy should pass along state when a stream is closed from end to<br>
>>> > end,<br>
>>> > not perfectly, but your connection should be properly reset at some<br>
>>> > point<br>
>>> > from the server going away.  There isn't anything that can be done in a<br>
>>> > protocol-neutral way that exceeds that, but that should be good enough<br>
>>> > for<br>
>>> > most uses.  Of course there are things that can disrupt the TCP state<br>
>>> > machine, or settings on a system can mean that connections aren't timed<br>
>>> > out<br>
>>> > when they should be.<br>
>>> ><br>
>>> > Are you using libuinet, FreeBSD, Linux, or something else for the TCP/IP<br>
>>> > stack?<br>
>>> ><br>
>>> > An easy change would be to add a heartbeat on all active sessions with<br>
>>> > WANProxy to actively probe for disconnected peers, but I'm not sure I'd<br>
>>> > encourage that.  If you think that would be helpful to you, let me know.<br>
>>> ><br>
>>> > Thanks,<br>
>>> > Juli.<br>
>>> ><br>
>>> > On Sat, Feb 24, 2018 at 1:09 AM, Ivan Pizhenko <<a href="mailto:ivan.pizhenko@gmail.com">ivan.pizhenko@gmail.com</a>><br>
>>> > wrote:<br>
>>> >><br>
>>> >> Hi,<br>
>>> >><br>
>>> >> I am making some tests with Wanproxy to understand how much it is<br>
>>> >> stable and reliable. I am using latest Wanproxy code from Github and<br>
>>> >> work on Ubuntu 16.04 LTS with kernel 4.13 and all latest updates.<br>
>>> >><br>
>>> >> I have conducted following simple test:<br>
>>> >><br>
>>> >> I have installed locally Apache 2 HTTP Server and put some large file<br>
>>> >> into the document root. Then I have configured, also locally, "client"<br>
>>> >> and "server" Wanproxy similar to how it is described in examples<br>
>>> >> section on <a href="http://wanproxy.org" rel="noreferrer" target="_blank">wanproxy.org</a>, but without ssh tunnel between them, to proxy<br>
>>> >> Apaches's HTTP port. Then I have used wget to download that large file<br>
>>> >> through "client" Wanproxy. It worked fine but slower than direct<br>
>>> >> download from Apache. Then I have tried to do the same thing but  I<br>
>>> >> have shut down "server" Wanproxy somewhere in the middle of download.<br>
>>> >> The download has freezed, the were no further progress. When I have<br>
>>> >> restarted "server" Wanproxy, the download did not resume. When I shut<br>
>>> >> down client Wanproxy, wget showed error like "connection refused" and<br>
>>> >> exited.<br>
>>> >><br>
>>> >> I would expect that when "server" Wanproxy went down, "client" one<br>
>>> >> would disconnect clients connected to it to indicate that upstream<br>
>>> >> link is broken, if not immediately, then after some reasonable<br>
>>> >> timeout. Is there a way to achieve something like this with Wanproxy?<br>
>>> >> If not, what changes to Wanproxy are needed to enable such<br>
>>> >> functionality?<br>
>>> >><br>
>>> >> Ivan.<br>
>>> >> ______________________________<wbr>_________________<br>
>>> >> wanproxy mailing list<br>
>>> >> <a href="mailto:wanproxy@lists.wanproxy.org">wanproxy@lists.wanproxy.org</a><br>
>>> >> <a href="http://lists.wanproxy.org/listinfo.cgi/wanproxy-wanproxy.org" rel="noreferrer" target="_blank">http://lists.wanproxy.org/<wbr>listinfo.cgi/wanproxy-<wbr>wanproxy.org</a><br>
>>> ><br>
>>> ><br>
>><br>
>><br>
</div></div></blockquote></div><br></div>