1

Attempting to make a JDBC connection from client (Windows Server 2012) to server (MSSQL Server 2012 SP2 hosted on Windows Server) results in this error:

Connection Timeout Expired.  The timeout period elapsed while attempting to consume the pre-login handshake acknowledgement.  This could be because the pre-login handshake failed or the server was unable to respond back in time.  The duration spent while attempting to connect to this server was - [Pre-Login] initialization=273; handshake=29736;  (Microsoft SQL Server, Error: -2)

Packet trace analysis:

After the TCP handshake, the client sends a TDS pre-login packet to the server, but with the bytes representing the version all set to 0.  The server doesn't respond (though the protocol indicates the server MUST respond in some way), so the client re-transmits and eventually the client sends a TCP reset to the server. 

Additional details:

  • Port 1433 is open on both the client and server.
  • No network or software is filtering traffic from client to server.
  • Connectivity to the server is successful from other machines on different domains using the same connection string.
  • Connectivity is successful from client to server at the data link layer (tested using Data Link Editor).
  • TCP/IP is enabled for IPv4 and IPv6 on both the client and server.
  • TLS is enabled on both servers.
  • We have tried 3 different JDBC drivers using Squirrel SQL & MSSQL Server Management Studio.  All provide the same error.  The drivers refer to the correct DLLs.
  • Tracert from client to server completes successfully.
  • We have tried modifying the connection string to force trust of the server certification, force encryption, increase connection timeout value to several minutes, etc.
  • .NET 4.5 is used on the client, but .NET 4.5 is also used on other machines that can successfully connect to the server.

What could be the issue? I'm out of ideas.

autotelic
  • 11
  • 1
  • Have you tried increasing the timeout to see if it's a legitimate timeout? I know you said no software is filtering traffic, but this does smell like a firewall problem. Maybe check A/V? – Jacob H Feb 22 '19 at 19:22
  • Where was the packet trace taken - the client machine or the SQL Server machine? – Brian Feb 22 '19 at 19:25
  • SQL Server Management Studio does not use JDBC drivers, so if you have the same problem in SQL Server Management Studio, your problem has nothing to do with the JDBC driver, but is more likely a networking or firewall issue. – Mark Rotteveel Feb 22 '19 at 20:17
  • @JacobH Increasing the timeout results in minutes of waiting until finally the client sends the TCP reset to the server. – autotelic Feb 22 '19 at 20:44
  • @Brian We ran the packet trace on the client machine. – autotelic Feb 22 '19 at 20:44
  • @MarkRotteveel Thank you for the clarification. We tested the 3 different drivers with Squirrel SQL. – autotelic Feb 22 '19 at 20:45
  • @JacobH We tested with antivirus disabled, and there was no difference. – autotelic Feb 22 '19 at 20:59
  • If you run the trace on the client and server machines both, can you account for all the packet traffic? In other words, does every packet that leaves the client reach the server, and vice versa? – Brian Feb 25 '19 at 22:01
  • @Brian I ran the trace on both machines this time. After the client sends the TDS pre-login message packet, I can see that the server never receives it, so it seems it's being dropped somewhere... The client re-transmits, and it looks like the server has multiple TCP handshakes with the client as a result. – autotelic Feb 28 '19 at 20:39
  • Glad to hear that you saw packet drops, @autotelic, in that it narrows the search space some. However, I'm afraid that I can't help you any further than that - I'm not a networking expert.. – Brian Feb 28 '19 at 20:48

0 Answers0