On Wed, 20 Apr 2016, KS Lee wrote:

> We have since upgraded the stack to libcurl 7.44 with OpenSSL 1.0.2d,and yet
> we still have the same issues as before. So, it doesn't seem to be related
> to old version of libcurl or OpenSSL.

Have you tried to identify the actual function call that is used when the
problem triggers? It could help us understand what's really going on.

> We have also captured Wireshark traces for both the "premature disconnection
> without proxy" and "no disconnection error with proxy" scenarios.

This is truly helpful!

> And, here is the trace of the same situation, but this time removing the
> software proxy. There are now a few resets coming from the libcurl side,
> NOT the peer host.
>
> Here is the issue. I don't know why the libcurl-side is sending a RST -- I
> don't understand TCP/IP in all its glory, so please forgive me if I'm
> missing something obvious here.

The RST comes from libcurl, in packet 95722 yes, and it concludes the use of
that TCP connection pretty much.

But before the RST, the client already sent FIN ACK in 95716 in the server
sent FIN ACK in 95718. It looks like a decent stream close to me, I can't see
where the problem lies here... :-/

RST after FIN ACK is pretty normal:
https://ask.wireshark.org/questions/13986/why-tcp-reset-sent-after-receive-finack-packet

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html