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: Aaron Ucko <ucko AT ncbi.nlm.nih.gov>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Reintegrating years of local FreeTDS changes
  • Date: Wed, 27 Jun 2018 11:16:27 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page