[openssl-users] Response from server is lost on close

[Anty Rao]

Hi,
yes, tcp is free to discard receive buffer on receiving RST
however after looking through the source code of linux kernel, it seems
that  process just set state of socket, not discard data in receive buffer.
1. tcp_validate_incoming

5184         /* Step 2: check RST bit */
5185         if (th->rst) {
5186                 tcp_reset(sk);
5187                 goto discard;
5188         }

2. tcp_reset

4055         if (!sock_flag(sk, SOCK_DEAD))
4056                 sk->sk_error_report(sk);
4057
4058         tcp_done(sk);

3. tcp_done
3183 void tcp_done(struct sock *sk)
3184 {
3185         if (sk->sk_state == TCP_SYN_SENT || sk->sk_state ==
TCP_SYN_RECV)
3186                 TCP_INC_STATS_BH(sock_net(sk), TCP_MIB_ATTEMPTFAILS);
3187
3188         tcp_set_state(sk, TCP_CLOSE);
3189         tcp_clear_xmit_timers(sk);
3190
3191         sk->sk_shutdown = SHUTDOWN_MASK;
3192
3193         if (!sock_flag(sk, SOCK_DEAD))
3194                 sk->sk_state_change(sk);
3195         else
3196                 inet_csk_destroy_sock(sk);
3197 }

On Thu, Dec 3, 2015 at 7:53 AM, Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> Just to amplify on Jakob's response: the reason that sometimes you see the
> reply is that sometimes your application manages to get it from the stack
> before the stack receives and processes the RST from the peer. In the
> example you provided, there was a 52ms window in which you could have read
> that response before the RST told the stack to throw it away.
>
>
>
> If the conversation is aborting for cause - for example because the peer
> process exited without reading some received data - then this is the
> correct behavior. If the peer is causing the RST by mucking around with the
> SO_LINGER socket option, then the peer application is probably broken.
> (There are cases where an application might legitimately want to send an
> RST rather than a FIN, but they're few and far between.)
>
>
>
> In any event, you're at the mercy of TCP's semantics. When the
> conversation is aborted, rather than terminated normally, unprocessed data
> goes away. That's a Good Thing, because the peer has no way of knowing
> whether you received it.
>
>
>
> As is usually the case with this sort of issue, the real question is what
> problem are you actually trying to solve? "How can I make TCP behave
> differently?" is not the right question.
>
>
>
> Michael Wojcik
> Technology Specialist, Micro Focus
>
>
>
>
>
> _______________________________________________
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Anty Rao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20151204/598cc861/attachment-0001.html>