TCP Nagle + TCP Delayed ACKs can cause what appears to be the ClientHello being retransmitted.
Tweaking these TCP options will give you better initialization performance. TCP_NODELAY TCP_QUICKACK This may not help the "end session" issue. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet." On Aug 20, 2018, at 9:39 AM, Viktor Dukhovni <openssl-us...@dukhovni.org<mailto:openssl-us...@dukhovni.org>> wrote: On Aug 17, 2018, at 6:43 AM, Konstantinos Schoinas <ece8...@upnet.gr<mailto:ece8...@upnet.gr>> wrote: So my dpdk application is responding with the correct TLS alert and it actually block the TLS session.I have seen the correct packet in wireshark as well.I am also putting a picture with this mail in order to see the process. The problem is that VM1 using openssl takes 2 to 3 seconds to end the TLS session.Also i am getting some retransmits of client hello in wireshark. Re-transmission is a feature of the kernel TCP stack, and OpenSSL has no control over this behaviour. So my question is if anyone can confirm that this is a problem of openssl or if not maybe something else. In addition if anyone know how much time does TLS session takes to actually end? This *cannot* be an OpenSSL issue. Your DPI firewall must not be sending an ACK for the client HELLO payload. Or is otherwise failing to conform to TCP in a way that triggers re-transmission. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users