Re: Reintegrating years of local FreeTDS changes

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 <[email protected]> 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 <[email protected]> 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
> [email protected]
> https://lists.ibiblio.org/mailman/listinfo/freetds
>