From jyan at tableau.com Mon Apr 3 11:21:54 2017 From: jyan at tableau.com (Johnny Yan) Date: Mon, 03 Apr 2017 15:21:54 -0000 Subject: [freetds] TDS_VERSION auto doesn't try from 7.4 nor preserve bad username/password error Message-ID: Hi, We accidentally found in your source code that the TDS_VERSIONs are defined in src/tds/config.c, 7.4 as the latest. However in src/tds/login.c, if TDS_VERSION is set to auto it started guessing TDS version from 7.3, not 7.4! /* * A major version of 0 means try to guess the TDS version. * We try them in an order that should work. */ const static TDS_USMALLINT versions[] = { 0x703 , 0x702 , 0x701 , 0x700 , 0x500 , 0x402 }; Why doesn't it start guessing from tds version 7.4? Meanwhile, when connecting with TDS_VERSION "auto", the bad username/password error is not preserved. It just gave an unknown error. Does the team have a plan to make this particular error more clear, i.e. preserve the bad username/password error? Thanks, Johnny From sf at 4js.com Mon May 22 11:36:19 2017 From: sf at 4js.com (Sebastien FLAESCH) Date: Mon, 22 May 2017 17:36:19 +0200 Subject: [freetds] SQL Server 2017 support Message-ID: <8404ac82-2c4d-58fd-59a1-ba4c20946542@4js.com> Hi, Is SQL Server 2017 supported by FreeTDS? Thanks Seb From joshua.h.lang at gmail.com Mon May 22 19:17:31 2017 From: joshua.h.lang at gmail.com (Joshua Lang) Date: Mon, 22 May 2017 16:17:31 -0700 Subject: [freetds] Parallel connections to SQL Server availability group Message-ID: I noticed that the master branch of FreeTDS has code to attempt connections to all IPs returned for a hostname in parallel. This functionality is not currently in the 1.00 branch, however. This leads to slow connections when using AGs and the client happens to pick the wrong IP address to connect to first because the 1.00 branch attempts to connection to each IP address in sequence. Any idea when the parallel implementation of this connection logic will be merged to the 1.00-branch or otherwise released? Thanks, -j From nem at emptec.com Tue May 2 21:14:30 2017 From: nem at emptec.com (Nem W Schlecht) Date: Wed, 03 May 2017 01:14:30 -0000 Subject: [freetds] defncopy core dump Message-ID: Hello all, Sorry, but it's been awhile since I compiled freetds (version 1.00.1 has been working just fine for me). My old favorite tool, defncopy, is core dumping again. :) Looks like these lines here: 577,578 if (sizeof(sql_text) <= dbcollen(dbproc, ctext) ) { assert(sizeof(sql_text) > dbcollen(dbproc, ctext)); The equal sign was moved from the line 578 to 577. This causes defncopy to core dump for me (Cygwin on Windows). If I move the equal sign back to the way it was in my older copy of code (1.00.1), then defncopy works perfectly again: 577,578 if (sizeof(sql_text) < dbcollen(dbproc, ctext) ) { assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); I see in the Changelog a change made by John Kendall on Aug 25th mentioning a fix for defncopy for ASE servers. Not sure how to get things to work for both systems. Thanks all! :) -- Nem W Schlecht "Perl did the magic. I just waved the wand." From john at capps.com Wed May 24 13:30:43 2017 From: john at capps.com (John Kendall) Date: Wed, 24 May 2017 17:30:43 +0000 Subject: [freetds] defncopy core dump In-Reply-To: References: Message-ID: <22CB6C55-BDB0-40D7-97A0-F6A508EA123D@capps.com> Hi, Nem. It looks like the change to lines 577 and 578 were made back in June 2016 (before mine). https://github.com/FreeTDS/freetds/commit/a67dc7502bf75d56c342f7af7b5d7e4dba826000 Fixing this issue shouldn't affect mine. John On May 2, 2017, at 6:12 PM, Nem W Schlecht wrote: > Hello all, > > Sorry, but it's been awhile since I compiled freetds (version 1.00.1 > has been working just fine for me). > > My old favorite tool, defncopy, is core dumping again. :) > > Looks like these lines here: > > 577,578 > if (sizeof(sql_text) <= dbcollen(dbproc, ctext) ) { > assert(sizeof(sql_text) > dbcollen(dbproc, ctext)); > > The equal sign was moved from the line 578 to 577. This causes > defncopy to core dump for me (Cygwin on Windows). > > If I move the equal sign back to the way it was in my older copy of > code (1.00.1), then defncopy works perfectly again: > > 577,578 > if (sizeof(sql_text) < dbcollen(dbproc, ctext) ) { > assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); > > I see in the Changelog a change made by John Kendall on Aug 25th > mentioning a fix for defncopy for ASE servers. Not sure how to get > things to work for both systems. > > Thanks all! :) > > -- > Nem W Schlecht > "Perl did the magic. I just waved the wand." > _______________________________________________ > FreeTDS mailing list > FreeTDS at mailman1.ibiblio.org > https://url.serverdata.net/?aYRdQGi3vXnuQJoWNSo02MmxBZ2G78s3rT1G4ZsYjcsqm3Z4xKVzDM1akvRgp9GkOw4EtE219pjbkUFsmgT8ImQ~~ From john at capps.com Wed May 24 13:30:43 2017 From: john at capps.com (John Kendall) Date: Wed, 24 May 2017 17:30:43 +0000 Subject: [freetds] defncopy core dump In-Reply-To: References: Message-ID: <22CB6C55-BDB0-40D7-97A0-F6A508EA123D@capps.com> Hi, Nem. It looks like the change to lines 577 and 578 were made back in June 2016 (before mine). https://github.com/FreeTDS/freetds/commit/a67dc7502bf75d56c342f7af7b5d7e4dba826000 Fixing this issue shouldn't affect mine. John On May 2, 2017, at 6:12 PM, Nem W Schlecht wrote: > Hello all, > > Sorry, but it's been awhile since I compiled freetds (version 1.00.1 > has been working just fine for me). > > My old favorite tool, defncopy, is core dumping again. :) > > Looks like these lines here: > > 577,578 > if (sizeof(sql_text) <= dbcollen(dbproc, ctext) ) { > assert(sizeof(sql_text) > dbcollen(dbproc, ctext)); > > The equal sign was moved from the line 578 to 577. This causes > defncopy to core dump for me (Cygwin on Windows). > > If I move the equal sign back to the way it was in my older copy of > code (1.00.1), then defncopy works perfectly again: > > 577,578 > if (sizeof(sql_text) < dbcollen(dbproc, ctext) ) { > assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); > > I see in the Changelog a change made by John Kendall on Aug 25th > mentioning a fix for defncopy for ASE servers. Not sure how to get > things to work for both systems. > > Thanks all! :) > > -- > Nem W Schlecht > "Perl did the magic. I just waved the wand." > _______________________________________________ > FreeTDS mailing list > FreeTDS at mailman1.ibiblio.org > https://url.serverdata.net/?aYRdQGi3vXnuQJoWNSo02MmxBZ2G78s3rT1G4ZsYjcsqm3Z4xKVzDM1akvRgp9GkOw4EtE219pjbkUFsmgT8ImQ~~ From nem at emptec.com Wed May 24 13:42:09 2017 From: nem at emptec.com (Nem W Schlecht) Date: Wed, 24 May 2017 12:42:09 -0500 Subject: [freetds] defncopy core dump In-Reply-To: <22CB6C55-BDB0-40D7-97A0-F6A508EA123D@capps.com> References: <22CB6C55-BDB0-40D7-97A0-F6A508EA123D@capps.com> Message-ID: Thanks John! The weird thing is that that is *my* patch! (At least I reported the bug). I'm not sure why the equal sign was moved, though. On Wed, May 24, 2017 at 12:30 PM, John Kendall wrote: > Hi, Nem. > It looks like the change to lines 577 and 578 were made back in June 2016 (before mine). > > https://github.com/FreeTDS/freetds/commit/a67dc7502bf75d56c342f7af7b5d7e4dba826000 > > Fixing this issue shouldn't affect mine. > > John > > > > On May 2, 2017, at 6:12 PM, Nem W Schlecht wrote: > >> Hello all, >> >> Sorry, but it's been awhile since I compiled freetds (version 1.00.1 >> has been working just fine for me). >> >> My old favorite tool, defncopy, is core dumping again. :) >> >> Looks like these lines here: >> >> 577,578 >> if (sizeof(sql_text) <= dbcollen(dbproc, ctext) ) { >> assert(sizeof(sql_text) > dbcollen(dbproc, ctext)); >> >> The equal sign was moved from the line 578 to 577. This causes >> defncopy to core dump for me (Cygwin on Windows). >> >> If I move the equal sign back to the way it was in my older copy of >> code (1.00.1), then defncopy works perfectly again: >> >> 577,578 >> if (sizeof(sql_text) < dbcollen(dbproc, ctext) ) { >> assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); >> >> I see in the Changelog a change made by John Kendall on Aug 25th >> mentioning a fix for defncopy for ASE servers. Not sure how to get >> things to work for both systems. >> >> Thanks all! :) >> >> -- >> Nem W Schlecht >> "Perl did the magic. I just waved the wand." >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at mailman1.ibiblio.org >> https://url.serverdata.net/?aYRdQGi3vXnuQJoWNSo02MmxBZ2G78s3rT1G4ZsYjcsqm3Z4xKVzDM1akvRgp9GkOw4EtE219pjbkUFsmgT8ImQ~~ > > _______________________________________________ > FreeTDS mailing list > FreeTDS at mailman1.ibiblio.org > http://mailman1.ibiblio.org/mailman/listinfo/freetds -- Nem W Schlecht "Perl did the magic. I just waved the wand." From nem at emptec.com Wed May 24 13:42:09 2017 From: nem at emptec.com (Nem W Schlecht) Date: Wed, 24 May 2017 12:42:09 -0500 Subject: [freetds] defncopy core dump In-Reply-To: <22CB6C55-BDB0-40D7-97A0-F6A508EA123D@capps.com> References: <22CB6C55-BDB0-40D7-97A0-F6A508EA123D@capps.com> Message-ID: Thanks John! The weird thing is that that is *my* patch! (At least I reported the bug). I'm not sure why the equal sign was moved, though. On Wed, May 24, 2017 at 12:30 PM, John Kendall wrote: > Hi, Nem. > It looks like the change to lines 577 and 578 were made back in June 2016 (before mine). > > https://github.com/FreeTDS/freetds/commit/a67dc7502bf75d56c342f7af7b5d7e4dba826000 > > Fixing this issue shouldn't affect mine. > > John > > > > On May 2, 2017, at 6:12 PM, Nem W Schlecht wrote: > >> Hello all, >> >> Sorry, but it's been awhile since I compiled freetds (version 1.00.1 >> has been working just fine for me). >> >> My old favorite tool, defncopy, is core dumping again. :) >> >> Looks like these lines here: >> >> 577,578 >> if (sizeof(sql_text) <= dbcollen(dbproc, ctext) ) { >> assert(sizeof(sql_text) > dbcollen(dbproc, ctext)); >> >> The equal sign was moved from the line 578 to 577. This causes >> defncopy to core dump for me (Cygwin on Windows). >> >> If I move the equal sign back to the way it was in my older copy of >> code (1.00.1), then defncopy works perfectly again: >> >> 577,578 >> if (sizeof(sql_text) < dbcollen(dbproc, ctext) ) { >> assert(sizeof(sql_text) >= dbcollen(dbproc, ctext)); >> >> I see in the Changelog a change made by John Kendall on Aug 25th >> mentioning a fix for defncopy for ASE servers. Not sure how to get >> things to work for both systems. >> >> Thanks all! :) >> >> -- >> Nem W Schlecht >> "Perl did the magic. I just waved the wand." >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at mailman1.ibiblio.org >> https://url.serverdata.net/?aYRdQGi3vXnuQJoWNSo02MmxBZ2G78s3rT1G4ZsYjcsqm3Z4xKVzDM1akvRgp9GkOw4EtE219pjbkUFsmgT8ImQ~~ > > _______________________________________________ > FreeTDS mailing list > FreeTDS at mailman1.ibiblio.org > http://mailman1.ibiblio.org/mailman/listinfo/freetds -- Nem W Schlecht "Perl did the magic. I just waved the wand." From campbellg at teds.com Thu May 25 08:07:48 2017 From: campbellg at teds.com (Glenn Campbell) Date: Thu, 25 May 2017 12:07:48 +0000 Subject: [freetds] can't build dll with gnutls on Windows Message-ID: I need a freetds dll that uses gnutls instead of openssl for an old Windows application that uses db-library. All of the pre-built binaries I've found use openssl instead of gnutls. I attempted to build it myself but unfortunately I haven't been able to do so. I am new to CMake but as best I can tell the CMakeLists.txt doesn't try to locate the gnutls artifacts. So, I downloaded the gnutls windows binary package, made some ugly hacks to the CMakeLists.txt file, and set the CMAKE_PREFIX_PATH environment variable so that CMake appears to be locating the gnutls artifacts. However, when I open the generated sln file in Visual Studio 2013 and attempt to build the dll I get errors from gnutls.h that seem to indicate that ssize_t is undefined. So I'm stuck at this point. After getting stuck trying to use CMake I decided to try MingW. And when I got stuck with MingW I tried Cygwin. My results with both MingW and Cygwin were similar. I am unfamiliar with both of them and there appear to be a lot of steps I'm missing between "download and install MingW (or Cygwin)" and "build the freetds windows dll". Can anyone point me in the right direction? I just need a freetds dll using gnutls and its corresponding lib file so that I can rebuild my application with Visual Studio. It doesn't matter much to me how I have to generate the dll (CMake/MingW/Cygwin). Thanks in advance. From freddy77 at gmail.com Fri Jun 2 04:42:21 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 2 Jun 2017 09:42:21 +0100 Subject: [freetds] SQL Server 2017 support In-Reply-To: <8404ac82-2c4d-58fd-59a1-ba4c20946542@4js.com> References: <8404ac82-2c4d-58fd-59a1-ba4c20946542@4js.com> Message-ID: 2017-05-22 16:36 GMT+01:00 Sebastien FLAESCH : > Hi, > > Is SQL Server 2017 supported by FreeTDS? > > Thanks > Seb Yes and no. Yes as the db is back compatible. No as I don't even know the new feature (at protocol level) or sql 2017. Frediano From freddy77 at gmail.com Fri Jun 2 04:42:21 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 2 Jun 2017 09:42:21 +0100 Subject: [freetds] SQL Server 2017 support In-Reply-To: <8404ac82-2c4d-58fd-59a1-ba4c20946542@4js.com> References: <8404ac82-2c4d-58fd-59a1-ba4c20946542@4js.com> Message-ID: 2017-05-22 16:36 GMT+01:00 Sebastien FLAESCH : > Hi, > > Is SQL Server 2017 supported by FreeTDS? > > Thanks > Seb Yes and no. Yes as the db is back compatible. No as I don't even know the new feature (at protocol level) or sql 2017. Frediano From freddy77 at gmail.com Fri Jun 2 04:47:19 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 2 Jun 2017 09:47:19 +0100 Subject: [freetds] can't build dll with gnutls on Windows In-Reply-To: References: Message-ID: 2017-05-25 13:07 GMT+01:00 Glenn Campbell : > I need a freetds dll that uses gnutls instead of openssl for an old Windows > application that uses db-library. All of the pre-built binaries I've found > use openssl instead of gnutls. I attempted to build it myself but > unfortunately I haven't been able to do so. > > I am new to CMake but as best I can tell the CMakeLists.txt doesn't try to > locate the gnutls artifacts. So, I downloaded the gnutls windows binary > package, made some ugly hacks to the CMakeLists.txt file, and set the > CMAKE_PREFIX_PATH environment variable so that CMake appears to be locating > the gnutls artifacts. However, when I open the generated sln file in Visual > Studio 2013 and attempt to build the dll I get errors from gnutls.h that > seem to indicate that ssize_t is undefined. So I'm stuck at this point. > > After getting stuck trying to use CMake I decided to try MingW. And when I > got stuck with MingW I tried Cygwin. My results with both MingW and Cygwin > were similar. I am unfamiliar with both of them and there appear to be a > lot of steps I'm missing between "download and install MingW (or Cygwin)" > and "build the freetds windows dll". > > Can anyone point me in the right direction? I just need a freetds dll using > gnutls and its corresponding lib file so that I can rebuild my application > with Visual Studio. It doesn't matter much to me how I have to generate the > dll (CMake/MingW/Cygwin). > > Thanks in advance. Why not using OpenSSL? Don't use cygwin, FreeTDS fully support visual studio and MingW so I don't see a point in using cygwin, would just add a layer with no much value. I could give a try, don't think is too hard but I never used GnuTLS on Windows; can you give some advice? Can you post the errors you are getting? If is just a ssize_t problem maybe a simple include would solve it. ssize_t should be a C99 standard type so maybe you could get better results with VS 2015. Frediano From freddy77 at gmail.com Fri Jun 2 04:55:10 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 2 Jun 2017 09:55:10 +0100 Subject: [freetds] Parallel connections to SQL Server availability group In-Reply-To: References: Message-ID: 2017-05-23 0:17 GMT+01:00 Joshua Lang : > I noticed that the master branch of FreeTDS has code to attempt connections > to all IPs returned for a hostname in parallel. This functionality is not > currently in the 1.00 branch, however. > > This leads to slow connections when using AGs and the client happens to > pick the wrong IP address to connect to first because the 1.00 branch > attempts to connection to each IP address in sequence. > > Any idea when the parallel implementation of this connection logic will be > merged to the 1.00-branch or otherwise released? > > Thanks, > > -j I usually don't backport new feature. The master branch is stable for mssql, not for Sybase, there are some regression due to different data types. No idea when 1.1 (so when Sybase will be fully fixed) will be available. Frediano From freddy77 at gmail.com Fri Jun 2 04:55:10 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Fri, 2 Jun 2017 09:55:10 +0100 Subject: [freetds] Parallel connections to SQL Server availability group In-Reply-To: References: Message-ID: 2017-05-23 0:17 GMT+01:00 Joshua Lang : > I noticed that the master branch of FreeTDS has code to attempt connections > to all IPs returned for a hostname in parallel. This functionality is not > currently in the 1.00 branch, however. > > This leads to slow connections when using AGs and the client happens to > pick the wrong IP address to connect to first because the 1.00 branch > attempts to connection to each IP address in sequence. > > Any idea when the parallel implementation of this connection logic will be > merged to the 1.00-branch or otherwise released? > > Thanks, > > -j I usually don't backport new feature. The master branch is stable for mssql, not for Sybase, there are some regression due to different data types. No idea when 1.1 (so when Sybase will be fully fixed) will be available. Frediano From sfhacker at hotmail.com Fri Jun 2 07:38:17 2017 From: sfhacker at hotmail.com (Sergio NNX) Date: Fri, 2 Jun 2017 11:38:17 +0000 Subject: [freetds] can't build dll with gnutls on Windows In-Reply-To: References: , Message-ID: > I need a freetds dll that uses gnutls instead of openssl for an old Windows > application that uses db-library. All of the pre-built binaries I've found > use openssl instead of gnutls. I attempted to build it myself but > unfortunately I haven't been able to do so. I've read on several mailing lists that the use of gnuTLS is strongly discouraged! > After getting stuck trying to use CMake I decided to try MingW. And when I > got stuck with MingW I tried Cygwin. My results with both MingW and Cygwin > were similar. I am unfamiliar with both of them and there appear to be a > lot of steps I'm missing between "download and install MingW (or Cygwin)" > and "build the freetds windows dll". It sounds really odd that neither VS nor CMake nor MinGW nor Cygwin worked! ? > I could give a try, don't think is too hard but I never used GnuTLS on Windows; > can you give some advice? That sounds that it has never been tested? We have never used gnuTLS but I've already built it from source successfully and now I'm compiling freeTDS from master. So far I can see some 'interesting' things going on. I'll report back soon. Ciao. From freddy77 at gmail.com Tue Jun 6 18:49:22 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Tue, 6 Jun 2017 23:49:22 +0100 Subject: [freetds] can't build dll with gnutls on Windows In-Reply-To: References: Message-ID: 2017-06-02 12:38 GMT+01:00 Sergio NNX : >> I need a freetds dll that uses gnutls instead of openssl for an old Windows >> application that uses db-library. All of the pre-built binaries I've found >> use openssl instead of gnutls. I attempted to build it myself but >> unfortunately I haven't been able to do so. > > I've read on several mailing lists that the use of gnuTLS is strongly discouraged! > > Personally I didn't find any recent post about it. >From API prospective I prefer GnuTLS, also the choice of algorithms seems better in GnuTLS (OpenSSL keeps old not that secure stuff enabled by default). It seems nobody (me too) tested FreeTDS with GnuTLS under Windows. >> After getting stuck trying to use CMake I decided to try MingW. And when I >> got stuck with MingW I tried Cygwin. My results with both MingW and Cygwin >> were similar. I am unfamiliar with both of them and there appear to be a >> lot of steps I'm missing between "download and install MingW (or Cygwin)" >> and "build the freetds windows dll". > > It sounds really odd that neither VS nor CMake nor MinGW nor Cygwin worked! ? > Maybe the problem is using GnuTLS on Windows... no idea how to do it. Cygwin is not encouraged at all. I think MinGW means autoconf stuff trying to compile like under Unix. FreeTDS CMake files does not support this kind of configuration so saying that CMake should be used to generate VS project file I think this is the issue with CMake trying Windows+FreeTDS+GnuTLS. >> I could give a try, don't think is too hard but I never used GnuTLS on Windows; >> can you give some advice? > That sounds that it has never been tested? > Yes! But apparently it seems this was never an issue before some weeks ago :-) Not clear why OpenSSL is not a solution in this case. AppVeyor generate binaries for Windows, are these binaries not enough? Maybe the tools (tsql and so on) are missing? > > We have never used gnuTLS but I've already built it from source successfully and now I'm compiling freeTDS from master. So far I can see some 'interesting' things going on. I'll report back soon. > > > Ciao. Ciao, Frediano From fredy at opag.ch Sat Jun 24 03:24:17 2017 From: fredy at opag.ch (Fredy Paquet) Date: Sat, 24 Jun 2017 09:24:17 +0200 Subject: [freetds] Sybase Connection - trouble without protocol fallback Message-ID: <1498289057.3704.10.camel@opag.ch> Yesterday, i have compiled freetds from a fresh pull of the git master branch on CentOS7. Trying to connect to a sybase service, using a freetds.conf entry, the connection always failed with "Login incorrect.". Testing using fisql with -Hhost:port was successfully connecting. After twiddling around, we found out that: - Connecting via freetds.conf works if the "tds protocol = 5" entry is removed. Removing it, enables the protocol fallback from 7.3 downwards. Using ?tds version = 5.0? always fails after first response packet. Any suggestions ? -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 From freddy77 at gmail.com Sun Jun 25 12:47:19 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Sun, 25 Jun 2017 17:47:19 +0100 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1498289057.3704.10.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> Message-ID: 2017-06-24 8:24 GMT+01:00 Fredy Paquet : > Yesterday, i have compiled freetds from a fresh pull of the git master > branch on CentOS7. > > Trying to connect to a sybase service, using a freetds.conf entry, the > connection always failed with "Login incorrect.". Testing using fisql > with -Hhost:port was successfully connecting. > > After twiddling around, we found out that: > > - Connecting via freetds.conf works if the "tds protocol = 5" entry is > removed. Removing it, enables the protocol fallback from 7.3 downwards. > "tds protocol" does not exist. Old versions ignore any additional not supported options. > Using ?tds version = 5.0? always fails after first response packet. > What does it mean? That FreeTDS send a packet and then the login fails? Are you getting some feedback from the server? Have you tried tsql and TDSVER=5.0 (environment variable) ? > Any suggestions ? > Try to use TDSDUMPCONFIG or TDSDUMP if this shed some light. You can post (privately if you want) some dumps (should not be really long as login is failing). Frediano From lacak at zoznam.sk Mon Jun 26 01:20:37 2017 From: lacak at zoznam.sk (LacaK) Date: Mon, 26 Jun 2017 07:20:37 +0200 Subject: [freetds] FreeTDS in Debian/Ubuntu package repository Message-ID: Hi, There is FreeTDS 1.0 more than one year released, but Debian/Ubuntu package repositories still lists old 0.91-6 versions: https://packages.ubuntu.com/yakkety/libs/freetds-bin I do not know how are these packages in repositories maintained, but is there any way how to update version of FreeTDS ? Thanks -Laco. From fredy at opag.ch Mon Jun 26 01:10:25 2017 From: fredy at opag.ch (Fredy Paquet) Date: Mon, 26 Jun 2017 07:10:25 +0200 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: References: <1498289057.3704.10.camel@opag.ch> Message-ID: <1498453825.4532.10.camel@opag.ch> Hello Frediano Attached, there are two TDSDUMPs which were produced using the compiled fisql command. You can see the login packets using protocol version 5.0 are slightly different. Between the two runs we were just commenting out the "tds version" line. We've stripped out some config search lines for clarity ... It looks to me as if something isn't reset correctly between the trials. I have some time this week to help searching. Can you give me some pointers where to start searching? fp -- fisql_bad.log $ vs $FREETDS [MOKO] host = 192.168.100.2 port = 2025 tds version = 5.0 $ setenv TDSDUMP /tmp/fisql_bad.log $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null Changed database context to 'casy'. $ vs $TDSDUMP # Search for: tds_process_login_tokens() -- fisql_ok.log $ vs $FREETDS [MOKO] host = 192.168.100.2 port = 2025 # tds version = 5.0 $ setenv TDSDUMP /tmp/fisql_ok.log $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null Changed database context to 'casy'. $ vs $TDSDUMP > > Try to use TDSDUMPCONFIG or TDSDUMP if this shed some light. > You can post (privately if you want) some dumps (should not be really > long as login is failing). > > Frediano > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 -------------- next part -------------- A non-text attachment was scrubbed... Name: fisql_bad.log Type: text/x-log Size: 9036 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fisql_ok.log Type: text/x-log Size: 16037 bytes Desc: not available URL: From freddy77 at gmail.com Mon Jun 26 10:49:16 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 26 Jun 2017 15:49:16 +0100 Subject: [freetds] FreeTDS in Debian/Ubuntu package repository In-Reply-To: References: Message-ID: 2017-06-26 6:20 GMT+01:00 LacaK : > Hi, > > There is FreeTDS 1.0 more than one year released, but Debian/Ubuntu package > repositories still lists old 0.91-6 versions: > https://packages.ubuntu.com/yakkety/libs/freetds-bin > > I do not know how are these packages in repositories maintained, but is > there any way how to update version of FreeTDS ? > > Thanks > > -Laco. > Use the source! :-) Yes, Debian guys should update a bit more often. You can use this bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803258. Or contact directly maintainers (see https://packages.debian.org/stretch/freetds-bin). Frediano From freddy77 at gmail.com Mon Jun 26 11:33:48 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 26 Jun 2017 16:33:48 +0100 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1498453825.4532.10.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> Message-ID: 2017-06-26 6:10 GMT+01:00 Fredy Paquet : > Hello Frediano > > Attached, there are two TDSDUMPs which were produced using the compiled > fisql command. You can see the login packets using protocol version 5.0 > are slightly different. > > Between the two runs we were just commenting out the "tds version" line. > We've stripped out some config search lines for clarity ... > > It looks to me as if something isn't reset correctly between the trials. > I have some time this week to help searching. > > Can you give me some pointers where to start searching? > Can you try adding encryption = request to the configuration entries ?? > fp > > -- fisql_bad.log > > $ vs $FREETDS > [MOKO] > host = 192.168.100.2 > port = 2025 > tds version = 5.0 > yes, kind of here. > $ setenv TDSDUMP /tmp/fisql_bad.log > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > Changed database context to 'casy'. > $ vs $TDSDUMP > # Search for: tds_process_login_tokens() > > -- fisql_ok.log > > $ vs $FREETDS > [MOKO] > host = 192.168.100.2 > port = 2025 > # tds version = 5.0 > > $ setenv TDSDUMP /tmp/fisql_ok.log > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > Changed database context to 'casy'. > $ vs $TDSDUMP > > >> >> Try to use TDSDUMPCONFIG or TDSDUMP if this shed some light. >> You can post (privately if you want) some dumps (should not be really >> long as login is failing). >> Frediano From lacak at zoznam.sk Tue Jun 27 01:29:25 2017 From: lacak at zoznam.sk (LacaK) Date: Tue, 27 Jun 2017 07:29:25 +0200 Subject: [freetds] FreeTDS in Debian/Ubuntu package repository In-Reply-To: References: Message-ID: <7c68d335-35c9-3cbb-49b0-611a9f4206f2@zoznam.sk> > Use the source! :-) > > Yes, Debian guys should update a bit more often. You can use this bug > report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803258. I send request using email (with CC to FreeTDS list) > Or contact directly maintainers I sended email 2 months ago already, but with no response L. From lacak at zoznam.sk Tue Jun 27 01:26:13 2017 From: lacak at zoznam.sk (LacaK) Date: Tue, 27 Jun 2017 07:26:13 +0200 Subject: [freetds] Update FreeTDS package Message-ID: <3e8e899d-e4ee-f206-e922-6c1c16514c5f@zoznam.sk> Package: freetds Version: 1.0 Severity: wishlist Hello, FreeTDS has released a new version, 1.0 a year ago, please update freetds package in Debian as well. Regards, -Laco. From fredy at opag.ch Wed Jun 28 03:12:15 2017 From: fredy at opag.ch (Fredy Paquet) Date: Wed, 28 Jun 2017 09:12:15 +0200 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> Message-ID: <1498633935.3742.33.camel@opag.ch> OK, got it. I am debugging a Adaptive Server Enterprise/15.7.0/EBF 19805 SMP ESD#01 failed login requests: FreeTDS 1.1.dev.20170626 [MOKO] tds version = 5.0, encryption = off -- fails to connect [MOKO] tds version = 5.0, encryption = request -- connects [MOKO] tds version = 5.0, encryption = require -- connects [MOKO] no tds version, no encryption setting -- fails to connect FreeTDS 0.91 [MOKO] tds version = 5.0, encryption = off -- connects [MOKO] tds version = 5.0, encryption = request -- fails [MOKO] tds version = 5.0, encryption = require -- fails This is due to the fact that in login.c(Line 1128) in function tds71_do_login() the encryption level is set to REQUEST, but never reset again: if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) login->encryption_level = TDS_ENCRYPTION_REQUEST; This could easily fixed by saving/restoring the encryption level, but i'm asking me whether if there are other modified fields not being restored properly. The protocol fallback loop is in login.c Line 404. -- Besides the fact that encryption is highly recommended, there must have been introduced a bug with "encryption off" between V0.91 and V1.1. This bug will create migration problems when upgrading to the new FreeTDS version. I'm doing further investigations on this. fp On Mon, 2017-06-26 at 16:33 +0100, Frediano Ziglio wrote: > 2017-06-26 6:10 GMT+01:00 Fredy Paquet : > > Hello Frediano > > > > Attached, there are two TDSDUMPs which were produced using the compiled > > fisql command. You can see the login packets using protocol version 5.0 > > are slightly different. > > > > Between the two runs we were just commenting out the "tds version" line. > > We've stripped out some config search lines for clarity ... > > > > It looks to me as if something isn't reset correctly between the trials. > > I have some time this week to help searching. > > > > Can you give me some pointers where to start searching? > > > > Can you try adding > > encryption = request > > to the configuration entries ?? > > > fp > > > > -- fisql_bad.log > > > > $ vs $FREETDS > > [MOKO] > > host = 192.168.100.2 > > port = 2025 > > tds version = 5.0 > > > > yes, kind of here. > > > $ setenv TDSDUMP /tmp/fisql_bad.log > > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > > Changed database context to 'casy'. > > $ vs $TDSDUMP > > # Search for: tds_process_login_tokens() > > > > -- fisql_ok.log > > > > $ vs $FREETDS > > [MOKO] > > host = 192.168.100.2 > > port = 2025 > > # tds version = 5.0 > > > > $ setenv TDSDUMP /tmp/fisql_ok.log > > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > > Changed database context to 'casy'. > > $ vs $TDSDUMP > > > > > >> > >> Try to use TDSDUMPCONFIG or TDSDUMP if this shed some light. > >> You can post (privately if you want) some dumps (should not be really > >> long as login is failing). > >> > > Frediano -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 From fredy at opag.ch Wed Jun 28 03:50:07 2017 From: fredy at opag.ch (Fredy Paquet) Date: Wed, 28 Jun 2017 09:50:07 +0200 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1498633935.3742.33.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> <1498633935.3742.33.camel@opag.ch> Message-ID: <1498636207.3742.36.camel@opag.ch> Addendum FreeTDS 0.95.81 [MOKO] tds version = 5.0, encryption = off -- connects [MOKO] tds version = 5.0, encryption = request -- fails [MOKO] tds version = 5.0, encryption = require -- fails [MOKO] no tds version, no encryption setting -- connects with V4.2 On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: > OK, got it. > > I am debugging a Adaptive Server Enterprise/15.7.0/EBF 19805 SMP ESD#01 > failed login requests: > > FreeTDS 1.1.dev.20170626 > > [MOKO] tds version = 5.0, encryption = off -- fails to connect > [MOKO] tds version = 5.0, encryption = request -- connects > [MOKO] tds version = 5.0, encryption = require -- connects > [MOKO] no tds version, no encryption setting -- fails to connect > > FreeTDS 0.91 > > [MOKO] tds version = 5.0, encryption = off -- connects > [MOKO] tds version = 5.0, encryption = request -- fails > [MOKO] tds version = 5.0, encryption = require -- fails > > This is due to the fact that in login.c(Line 1128) in function > tds71_do_login() the encryption level is set to REQUEST, but never reset > again: > > if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > login->encryption_level = TDS_ENCRYPTION_REQUEST; > > This could easily fixed by saving/restoring the encryption level, but > i'm asking me whether if there are other modified fields not being > restored properly. The protocol fallback loop is in login.c Line 404. > > -- > Besides the fact that encryption is highly recommended, there must > have been introduced a bug with "encryption off" between V0.91 and V1.1. > > This bug will create migration problems when upgrading to the new > FreeTDS version. I'm doing further investigations on this. > > fp > > On Mon, 2017-06-26 at 16:33 +0100, Frediano Ziglio wrote: > > 2017-06-26 6:10 GMT+01:00 Fredy Paquet : > > > Hello Frediano > > > > > > Attached, there are two TDSDUMPs which were produced using the compiled > > > fisql command. You can see the login packets using protocol version 5.0 > > > are slightly different. > > > > > > Between the two runs we were just commenting out the "tds version" line. > > > We've stripped out some config search lines for clarity ... > > > > > > It looks to me as if something isn't reset correctly between the trials. > > > I have some time this week to help searching. > > > > > > Can you give me some pointers where to start searching? > > > > > > > Can you try adding > > > > encryption = request > > > > to the configuration entries ?? > > > > > fp > > > > > > -- fisql_bad.log > > > > > > $ vs $FREETDS > > > [MOKO] > > > host = 192.168.100.2 > > > port = 2025 > > > tds version = 5.0 > > > > > > > yes, kind of here. > > > > > $ setenv TDSDUMP /tmp/fisql_bad.log > > > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > > > Changed database context to 'casy'. > > > $ vs $TDSDUMP > > > # Search for: tds_process_login_tokens() > > > > > > -- fisql_ok.log > > > > > > $ vs $FREETDS > > > [MOKO] > > > host = 192.168.100.2 > > > port = 2025 > > > # tds version = 5.0 > > > > > > $ setenv TDSDUMP /tmp/fisql_ok.log > > > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > > > Changed database context to 'casy'. > > > $ vs $TDSDUMP > > > > > > > > >> > > >> Try to use TDSDUMPCONFIG or TDSDUMP if this shed some light. > > >> You can post (privately if you want) some dumps (should not be really > > >> long as login is failing). > > >> > > > > Frediano > -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29 From fredy at opag.ch Wed Jun 28 05:48:54 2017 From: fredy at opag.ch (Fredy Paquet) Date: Wed, 28 Jun 2017 11:48:54 +0200 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1498636207.3742.36.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> <1498633935.3742.33.camel@opag.ch> <1498636207.3742.36.camel@opag.ch> Message-ID: <1498643334.3742.46.camel@opag.ch> It turns out that the encryption level flag in the login packet is wrong for SYBASE. Successfull 2nd login packet from FreeTDS 0.91: net.c:741:Sending packet 0000 02 01 00 61 00 00 00 00-00 00 00 00 00 00 0a 00 |...a.... ........| 0010 00 00 00 00 00 00 00 00-00 00 00 00 00 69 73 6f |........ .....iso| Failed 2nd login packet from FreeTDS 1.1.dev.20170626 packet.c:742:Sending packet 0000 02 01 00 6b 00 00 00 00-00 00 00 00 00 00 0a 00 |...k.... ........| 0010 00 00 a0 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| (look at byte at index 0x0012) After changing the following source line in login.c function tds_send_login() at line 746: tds_put_byte(tds, login->encryption_level ? TDS5_SEC_LOG_ENCRYPT2| TDS5_SEC_LOG_NONCE : 0); to tds_put_byte(tds, 0); The unencrypted login is SUCCESSFUL. --- Printing out login->encryption_level at the moment of packet assembly, we get: login.c:747:Encryption level 1. while the config file contains "encryption = off". When looking at the definition of TDS_ENCRYPTION_LEVEL, we find that this corresponds to the enum value TDS_ENCRYPTION_OFF, wich is 1. The value TDS_ENCRYPTION_DEFAULT is 0. --- I suggest that the test is wrong. fp On Wed, 2017-06-28 at 09:50 +0200, Fredy Paquet wrote: > Addendum > > FreeTDS 0.95.81 > [MOKO] tds version = 5.0, encryption = off -- connects > [MOKO] tds version = 5.0, encryption = request -- fails > [MOKO] tds version = 5.0, encryption = require -- fails > [MOKO] no tds version, no encryption setting -- connects with V4.2 > > On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: > > OK, got it. > > > > I am debugging a Adaptive Server Enterprise/15.7.0/EBF 19805 SMP ESD#01 > > failed login requests: > > > > FreeTDS 1.1.dev.20170626 > > > > [MOKO] tds version = 5.0, encryption = off -- fails to connect > > [MOKO] tds version = 5.0, encryption = request -- connects > > [MOKO] tds version = 5.0, encryption = require -- connects > > [MOKO] no tds version, no encryption setting -- fails to connect > > > > FreeTDS 0.91 > > > > [MOKO] tds version = 5.0, encryption = off -- connects > > [MOKO] tds version = 5.0, encryption = request -- fails > > [MOKO] tds version = 5.0, encryption = require -- fails > > > > This is due to the fact that in login.c(Line 1128) in function > > tds71_do_login() the encryption level is set to REQUEST, but never reset > > again: > > > > if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > > login->encryption_level = TDS_ENCRYPTION_REQUEST; > > > > This could easily fixed by saving/restoring the encryption level, but > > i'm asking me whether if there are other modified fields not being > > restored properly. The protocol fallback loop is in login.c Line 404. > > > > -- > > Besides the fact that encryption is highly recommended, there must > > have been introduced a bug with "encryption off" between V0.91 and V1.1. > > > > This bug will create migration problems when upgrading to the new > > FreeTDS version. I'm doing further investigations on this. > > > > fp > > > > On Mon, 2017-06-26 at 16:33 +0100, Frediano Ziglio wrote: > > > 2017-06-26 6:10 GMT+01:00 Fredy Paquet : > > > > Hello Frediano > > > > > > > > Attached, there are two TDSDUMPs which were produced using the compiled > > > > fisql command. You can see the login packets using protocol version 5.0 > > > > are slightly different. > > > > > > > > Between the two runs we were just commenting out the "tds version" line. > > > > We've stripped out some config search lines for clarity ... > > > > > > > > It looks to me as if something isn't reset correctly between the trials. > > > > I have some time this week to help searching. > > > > > > > > Can you give me some pointers where to start searching? > > > > > > > > > > Can you try adding > > > > > > encryption = request > > > > > > to the configuration entries ?? > > > > > > > fp > > > > > > > > -- fisql_bad.log > > > > > > > > $ vs $FREETDS > > > > [MOKO] > > > > host = 192.168.100.2 > > > > port = 2025 > > > > tds version = 5.0 > > > > > > > > > > yes, kind of here. > > > > > > > $ setenv TDSDUMP /tmp/fisql_bad.log > > > > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > > > > Changed database context to 'casy'. > > > > $ vs $TDSDUMP > > > > # Search for: tds_process_login_tokens() > > > > > > > > -- fisql_ok.log > > > > > > > > $ vs $FREETDS > > > > [MOKO] > > > > host = 192.168.100.2 > > > > port = 2025 > > > > # tds version = 5.0 > > > > > > > > $ setenv TDSDUMP /tmp/fisql_ok.log > > > > $ fisql -SMOKO -Ukommerz -Pguruguru < /dev/null > > > > Changed database context to 'casy'. > > > > $ vs $TDSDUMP > > > > > > > > > > > >> > > > >> Try to use TDSDUMPCONFIG or TDSDUMP if this shed some light. > > > >> You can post (privately if you want) some dumps (should not be really > > > >> long as login is failing). > > > >> > > > > > > Frediano > > > -- Fredy Paquet Mitglied der Gesch?ftsleitung OPAG Informatik AG Fabrikmattenweg 11 CH-4144 Arlesheim http://www.opag.ch Tel. ++41 61 716 92 22 Fax. ++41 61 716 92 29