Please reply to the list rather than to me directly. > From: Kamala Ayyar <kamala.ay...@gmail.com> > Sent: Thursday, 26 August, 2021 08:57
> We call the WSAGetLastError immediately after SSL_ERROR_SYSCALL and we get > the > WSAETIMEDOUT OK. This wasn't entirely clear to me from your previous message. So you are getting a network-stack timeout on a sockets operation; this isn't a TLS protocol issue or anything else at a level above the network stack. > We also call the ERR_print_errors(bio); but it displays a blank line. We call > ERR_clear_error() before the SSL_read as mentioned in the manual. I'm not sure why that might be happening. It may be that OpenSSL doesn't log any error messages in this case; I'd have to look at the OpenSSL source code to figure that out. > The ERR_print_errors() does not print anything- Is the error getting cleared > because we called the WSAGetLastError() ? That shouldn't affect the OpenSSL error list. > Is there an order in which the Windows WSAGetLastError() should be called > before > SSL_get_error()? I don't believe so. They should be independent. The OpenSSL error list is maintained by OpenSSL; WSAGetLastError retrieves the Winsock error code. The two don't share data. > We will try changing some of the timeouts on either side and try. Make sure that's stack timeouts you're changing: calls to setsockopt, or Registry settings if you're not overriding them on your sockets. Application-level timeouts aren't the issue here. You may need to involve a network administrator to look at network interface statistics, check wire traces to see if receive windows are closed, and look for interference from middleboxes such as routers and firewall appliances or from application firewalls, IDSes, and so on. These sorts of issues are not uncommon when there are load balancers, traffic-inspecting firewalls, or the like interfering with network traffic. -- Michael Wojcik
