FreeTDS Development Group

[Aaron Ucko <ucko AT ncbi.nlm.nih.gov>]

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