Skip to Content.
Sympa Menu

freetds - Re: [freetds] Reintegrating years of local FreeTDS changes

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Sebastien FLAESCH <sf AT 4js.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] Reintegrating years of local FreeTDS changes
  • Date: Wed, 27 Jun 2018 17:34:41 +0200

What I can tell is that with the standard source code compiled on my machine,
I have no problem to connect to SQL Server 2014.

Anyway at least no issues with SQL Server 2016 and 2017 so that's good news.

Seb

On 06/27/2018 05:16 PM, Aaron Ucko wrote:
Your 52 misses a few commits for which I merely credited myself as
Committer, but still amounts to at most 6 rounds of bisection, FWIW.

The log points to a TLS error, but without much in the way of specifics:

tls.c:1021:handshake failed with -1 4640 1

The -1 comes from SSL_connect, meaning

<0 The TLS/SSL handshake was not successful, because a fatal error
occurred either at the protocol level or a connection failure
occurred. The shutdown was not clean. It can also occur of action
is need to continue the operation for non-blocking BIOs. Call
SSL_get_error() with the return value ret to find out the reason.

The 4640 (0x1220) comes from SSL_get_state, where we have

#define SSL_ST_CONNECT 0x1000
#define SSL_CB_HANDSHAKE_DONE 0x20

and I'm not sure what to make of the 0x200; it may be some internal
flag. (I see an SSL_state_string_long function that may be more
informative.)

Finally, the 1 (SSL_ERROR_SSL) comes from SSL_get_error, meaning

SSL_ERROR_SSL
A failure in the SSL library occurred, usually a protocol error.
The OpenSSL error queue contains more information on the error.

I'm not sure how you'd get at the error queue. :-/

-- Aaron Ucko <ucko at ncbi>, NCBI C++ Toolkit core development group

Sebastien FLAESCH <sf AT 4js.com> writes:

Hummm...

sf@orion:/opt3/dbs/tds/tmp/freetds$ git log | grep "Author.* Ucko" | wc -l
52

Sorry I am cannot spend too much time on this.

Attached the TDSDUMP log, if it can help...

Or if you have any other compile option to debug what's going on
and is easily testable, let me know.

Seb



On 06/27/2018 03:40 PM, Aaron Ucko wrote:
That's not good (or intentional!), but I'm not sure why that would be;
that combination still works for me:

$ TDSVER=7.3 ./src/apps/tsql -o v -H MSDEV1 -p 1433 -U DBAPI_test
Password:
locale is
"LC_CTYPE=en_US.UTF-8;LC_NUMERIC=en_US.UTF-8;LC_TIME=en_US.UTF-8;LC_COLLATE=C;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=en_US.UTF-8;LC_ADDRESS=en_US.UTF-8;LC_TELEPHONE=en_US.UTF-8;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
1> SELECT @@version
2> go
using TDS version 7.3
Microsoft SQL Server 2014 (SP2-GDR) (KB4057120) - 12.0.5214.6 (X64)
Jan 9 2018 15:03:12
Copyright (c) Microsoft Corporation
Standard Edition (64-bit) on Windows NT 6.3 <X64> (Build 9600: )
(1 row affected)
using TDS version 7.3

Would you mind bisecting to determine which commit broke this
combination for you?

-- Aaron Ucko <ucko at ncbi>, NCBI C++ Toolkit core development group

Sebastien FLAESCH <sf AT 4js.com> writes:

I could execute our QA tests with SQL Server 2016 and 2017 without detecting
any regression, by using the "master" branch.

But it fails to connect to SQL Server 2014 (12.0).

Is there some limitation regarding the supported SQL Server version?

ODBCINI:

[ftm_msvtest1_ida_utf8]
Description = SQL Server 2014
Server = ida
Database = msvtest1
Port = 1681
TDS_Version = 7.3
ClientCharset = UTF-8


Seb
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
https://lists.ibiblio.org/mailman/listinfo/freetds






Archive powered by MHonArc 2.6.24.

Top of Page