From freddy77 at gmail.com Mon Jul 3 14:04:33 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 3 Jul 2017 19:04:33 +0100 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1498643334.3742.46.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> <1498643334.3742.46.camel@opag.ch> Message-ID: 2017-06-28 10:48 GMT+01:00 Fredy Paquet : > 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. > Yes, fixed! > fp > Thanks, Frediano > 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 > From fredy at opag.ch Tue Jul 4 09:15:26 2017 From: fredy at opag.ch (Fredy Paquet) Date: Tue, 04 Jul 2017 15:15:26 +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: <1499174126.5008.30.camel@opag.ch> Hello Frediano Thank you for the fix of the encryption flag in the login packet. (I will verify correct operation next saturday) What can we do about the fallback problem (see below) ? --- Proposal 1 Change the statment to use TDS_ENCRYPTION_OFF: if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) login->encryption_level = TDS_ENCRYPTION_OFF; Because default encryption level is defined as OFF. --- Proposal 2 I propose using a temporary local variable for the tds71-try, instead of modifying an entry in the login record, which is being used later for other protocol tries. in function tds71_do_login(): TDS_TINYINT my_encryption_level = (login->encryption_level == TDS_ENCRYPTION_DEFAULT) ? TDS_ENCRYPTION_REQUEST : login->encryption_level; then try with locally with my_encryption_level (this may be combined with Proposal 1) --- Proposal 3 Drop the whole statement, because encryption_level should be controlled by a freetds.conf setting. But on the other side, this might kill working freetds.conf configurations. What do you think about it ? fp On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: > > 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. -- 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 ikorot01 at gmail.com Tue Jul 4 10:37:36 2017 From: ikorot01 at gmail.com (Igor Korot) Date: Tue, 4 Jul 2017 10:37:36 -0400 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1499174126.5008.30.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> <1498633935.3742.33.camel@opag.ch> <1499174126.5008.30.camel@opag.ch> Message-ID: Hi, Fredy, On Tue, Jul 4, 2017 at 9:15 AM, Fredy Paquet wrote: > Hello Frediano > > Thank you for the fix of the encryption flag in the login packet. > (I will verify correct operation next saturday) > > What can we do about the fallback problem (see below) ? > > --- Proposal 1 > > Change the statment to use TDS_ENCRYPTION_OFF: > > if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > login->encryption_level = TDS_ENCRYPTION_OFF; > > Because default encryption level is defined as OFF. What if the encryption becomes ON? How do you differentiate between them? Maybe we need to introduce something like DEFAULT for the encryption the configuration file? > > --- Proposal 2 > > I propose using a temporary local variable for the tds71-try, > instead of modifying an entry in the login record, which is being > used later for other protocol tries. > > in function tds71_do_login(): > > TDS_TINYINT my_encryption_level > = (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > ? TDS_ENCRYPTION_REQUEST : login->encryption_level; > > then try with locally with my_encryption_level > > (this may be combined with Proposal 1) > > --- Proposal 3 > > Drop the whole statement, because encryption_level should be controlled > by a freetds.conf setting. But on the other side, this might kill > working freetds.conf configurations. Probably not a good idea. Thank you. > > What do you think about it ? > > fp > > On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: >> >> 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. > > -- > 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 > > _______________________________________________ > FreeTDS mailing list > FreeTDS at lists.ibiblio.org > https://lists.ibiblio.org/mailman/listinfo/freetds From fredy at opag.ch Tue Jul 4 11:28:17 2017 From: fredy at opag.ch (Fredy Paquet) Date: Tue, 04 Jul 2017 17:28:17 +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> <1498633935.3742.33.camel@opag.ch> <1499174126.5008.30.camel@opag.ch> Message-ID: <1499182097.5008.57.camel@opag.ch> Hello Igor The FreeTDS user guide defines default encryption level is OFF: (see http://www.freetds.org/userguide/freetdsconf.htm) The config file parser initializes encryption_level to TDS_ENCRYPTION_DEFAULT. If you do not set encryption in any section of your freetds.conf, the encryption_level in the login struct remains at TDS_ENCRYPTION_DEFAULT. Today, the TDS 7.1 driver changes this value to TDS_ENCRYPTION_REQUEST, which doesn't implement the documented behaviour. I do not know wether MSSQL can accept unencrypted requests (no test system available). If MSSQL cannot accept unencrypted connections, it may be ok to fallback to TDS_ENCRYPTION_REQUEST for TDS 7.1. But this clearly must not affect further trials on the lower protocol levels. Agree, it would be good programming practise to introduce a #define for the default encryption level. fp On Tue, 2017-07-04 at 10:37 -0400, Igor Korot wrote: > Hi, Fredy, > > On Tue, Jul 4, 2017 at 9:15 AM, Fredy Paquet wrote: > > Hello Frediano > > > > Thank you for the fix of the encryption flag in the login packet. > > (I will verify correct operation next saturday) > > > > What can we do about the fallback problem (see below) ? > > > > --- Proposal 1 > > > > Change the statment to use TDS_ENCRYPTION_OFF: > > > > if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > > login->encryption_level = TDS_ENCRYPTION_OFF; > > > > Because default encryption level is defined as OFF. > > What if the encryption becomes ON? > How do you differentiate between them? > > Maybe we need to introduce something like DEFAULT for the encryption > the configuration file? > > > > > --- Proposal 2 > > > > I propose using a temporary local variable for the tds71-try, > > instead of modifying an entry in the login record, which is being > > used later for other protocol tries. > > > > in function tds71_do_login(): > > > > TDS_TINYINT my_encryption_level > > = (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > > ? TDS_ENCRYPTION_REQUEST : login->encryption_level; > > > > then try with locally with my_encryption_level > > > > (this may be combined with Proposal 1) > > > > --- Proposal 3 > > > > Drop the whole statement, because encryption_level should be controlled > > by a freetds.conf setting. But on the other side, this might kill > > working freetds.conf configurations. > > Probably not a good idea. > > Thank you. > > > > > What do you think about it ? > > > > fp > > > > On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: > >> > >> 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. > > > > -- > > 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 > > > > _______________________________________________ > > FreeTDS mailing list > > FreeTDS at lists.ibiblio.org > > https://lists.ibiblio.org/mailman/listinfo/freetds > _______________________________________________ > 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 From freddy77 at gmail.com Wed Jul 5 05:21:26 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 5 Jul 2017 10:21:26 +0100 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1499174126.5008.30.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> <1498633935.3742.33.camel@opag.ch> <1499174126.5008.30.camel@opag.ch> Message-ID: 2017-07-04 14:15 GMT+01:00 Fredy Paquet : > Hello Frediano > > Thank you for the fix of the encryption flag in the login packet. > (I will verify correct operation next saturday) > > What can we do about the fallback problem (see below) ? > > --- Proposal 1 > > Change the statment to use TDS_ENCRYPTION_OFF: > > if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > login->encryption_level = TDS_ENCRYPTION_OFF; > > Because default encryption level is defined as OFF. > In master is changed to request for MSSQL as MSSQL support encrypted login by default since 2005 and recent version started forbidding not encrypted logins. > --- Proposal 2 > > I propose using a temporary local variable for the tds71-try, > instead of modifying an entry in the login record, which is being > used later for other protocol tries. > > in function tds71_do_login(): > > TDS_TINYINT my_encryption_level > = (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > ? TDS_ENCRYPTION_REQUEST : login->encryption_level; > > then try with locally with my_encryption_level > > (this may be combined with Proposal 1) Already done this change in master, login structure is not changed now. > > --- Proposal 3 > > Drop the whole statement, because encryption_level should be controlled > by a freetds.conf setting. But on the other side, this might kill > working freetds.conf configurations. > Does not sound that great. > What do you think about it ? > > fp > > On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: >> >> 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. > > -- > 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 Wed Jul 5 05:24:30 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Wed, 5 Jul 2017 10:24:30 +0100 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1499182097.5008.57.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> <1498633935.3742.33.camel@opag.ch> <1499174126.5008.30.camel@opag.ch> <1499182097.5008.57.camel@opag.ch> Message-ID: 2017-07-04 16:28 GMT+01:00 Fredy Paquet : > Hello Igor > > The FreeTDS user guide defines default encryption level is OFF: > (see http://www.freetds.org/userguide/freetdsconf.htm) > > The config file parser initializes encryption_level to > TDS_ENCRYPTION_DEFAULT. If you do not set encryption in any section of > your freetds.conf, the encryption_level in the login struct remains at > TDS_ENCRYPTION_DEFAULT. > > Today, the TDS 7.1 driver changes this value to TDS_ENCRYPTION_REQUEST, > which doesn't implement the documented behaviour. > The website documentation reflect the last stable release where the default was OFF. > I do not know wether MSSQL can accept unencrypted requests (no test > system available). > Recent ones do not allow unencrypted logins. > If MSSQL cannot accept unencrypted connections, it may be ok to fallback > to TDS_ENCRYPTION_REQUEST for TDS 7.1. But this clearly must not affect > further trials on the lower protocol levels. > > Agree, it would be good programming practise to introduce a #define for > the default encryption level. > What do you mean? Is an enum not enough? > fp > Frediano From fredy at opag.ch Wed Jul 5 05:44:34 2017 From: fredy at opag.ch (Fredy Paquet) Date: Wed, 05 Jul 2017 11:44:34 +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> <1498633935.3742.33.camel@opag.ch> <1499174126.5008.30.camel@opag.ch> Message-ID: <1499247874.5484.5.camel@opag.ch> So this issue is also solved, i will verify correct operation with Sybase 15.7 next weekend. Thank you fp On Wed, 2017-07-05 at 10:21 +0100, Frediano Ziglio wrote: > 2017-07-04 14:15 GMT+01:00 Fredy Paquet : > > Hello Frediano > > > > Thank you for the fix of the encryption flag in the login packet. > > (I will verify correct operation next saturday) > > > > What can we do about the fallback problem (see below) ? > > > > --- Proposal 1 > > > > Change the statment to use TDS_ENCRYPTION_OFF: > > > > if (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > > login->encryption_level = TDS_ENCRYPTION_OFF; > > > > Because default encryption level is defined as OFF. > > > > In master is changed to request for MSSQL as MSSQL support encrypted login > by default since 2005 and recent version started forbidding not > encrypted logins. > > > --- Proposal 2 > > > > I propose using a temporary local variable for the tds71-try, > > instead of modifying an entry in the login record, which is being > > used later for other protocol tries. > > > > in function tds71_do_login(): > > > > TDS_TINYINT my_encryption_level > > = (login->encryption_level == TDS_ENCRYPTION_DEFAULT) > > ? TDS_ENCRYPTION_REQUEST : login->encryption_level; > > > > then try with locally with my_encryption_level > > > > (this may be combined with Proposal 1) > > Already done this change in master, login structure is not changed now. > > > > > --- Proposal 3 > > > > Drop the whole statement, because encryption_level should be controlled > > by a freetds.conf setting. But on the other side, this might kill > > working freetds.conf configurations. > > > > Does not sound that great. > > > What do you think about it ? > > > > fp > > > > On Wed, 2017-06-28 at 09:12 +0200, Fredy Paquet wrote: > >> > >> 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. > > > > -- > > 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 > > -- 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 Sat Jul 8 05:54:08 2017 From: fredy at opag.ch (Fredy Paquet) Date: Sat, 08 Jul 2017 11:54:08 +0200 Subject: [freetds] Sybase Connection - trouble without protocol fallback In-Reply-To: <1499247874.5484.5.camel@opag.ch> References: <1498289057.3704.10.camel@opag.ch> <1498453825.4532.10.camel@opag.ch> <1498633935.3742.33.camel@opag.ch> <1499174126.5008.30.camel@opag.ch> <1499247874.5484.5.camel@opag.ch> Message-ID: <1499507648.18099.15.camel@opag.ch> Hello Frediano Great job - ALL connection tests with Sybase 15.7.0 are successful. Many thanks fp --- Test results (fisql, fresh git pull, master branch) No encryption setting in freetds.conf (Default encryption): Default encryption, with protocol fallback: net.c:362:Connecting with protocol version 7.3 login.c:532:login packet rejected net.c:362:Connecting with protocol version 7.2 login.c:532:login packet rejected net.c:362:Connecting with protocol version 7.1 login.c:532:login packet rejected net.c:362:Connecting with protocol version 7.0 util.c:349:tdserror: client library returned TDS_INT_CANCEL(2) net.c:362:Connecting with protocol version 5.0 token.c:422:tds_process_login_tokens() returning TDS_SUCCESS Default encryption, without fallback: net.c:362:Connecting with protocol version 5.0 token.c:422:tds_process_login_tokens() returning TDS_SUCCESS No protocol fallback, with encryption = off net.c:362:Connecting with protocol version 5.0 0020 00 00 00 00 00 00 0b 6b-6f 6d 6d 65 72 7a 00 00 |.......k ommerz..| 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0040 00 00 00 00 00 07 67 75-72 75 67 75 72 75 00 00 |......gu ruguru..| token.c:422:tds_process_login_tokens() returning TDS_SUCCESS No protocol fallback, with encryption = request net.c:362:Connecting with protocol version 5.0 0020 00 00 00 00 00 00 0b 6b-6f 6d 6d 65 72 7a 00 00 |.......k ommerz..| 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0040 00 00 00 00 00 07 00 00-00 00 00 00 00 00 00 00 |........ ........| token.c:422:tds_process_login_tokens() returning TDS_SUCCESS No protocol fallback, with encryption = require net.c:362:Connecting with protocol version 5.0 0020 00 00 00 00 00 00 0b 6b-6f 6d 6d 65 72 7a 00 00 |.......k ommerz..| 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0040 00 00 00 00 00 07 00 00-00 00 00 00 00 00 00 00 |........ ........| token.c:422:tds_process_login_tokens() returning TDS_SUCCESS With fallback and encryption = off net.c:362:Connecting with protocol version 7.3 net.c:362:Connecting with protocol version 7.2 net.c:362:Connecting with protocol version 7.1 net.c:362:Connecting with protocol version 7.0 0020 00 00 00 00 00 00 0b 6b-6f 6d 6d 65 72 7a 00 00 |.......k ommerz..| 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0040 00 00 00 00 00 07 67 75-72 75 67 75 72 75 00 00 |......gu ruguru..| net.c:362:Connecting with protocol version 5.0 token.c:422:tds_process_login_tokens() returning TDS_SUCCESS With fallback and encryption = request net.c:362:Connecting with protocol version 7.3 net.c:362:Connecting with protocol version 7.2 net.c:362:Connecting with protocol version 7.1 net.c:362:Connecting with protocol version 7.0 net.c:362:Connecting with protocol version 5.0 0020 00 00 00 00 00 00 0b 6b-6f 6d 6d 65 72 7a 00 00 |.......k ommerz..| 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0040 00 00 00 00 00 07 00 00-00 00 00 00 00 00 00 00 |........ ........| token.c:422:tds_process_login_tokens() returning TDS_SUCCESS With fallback and encryption = require net.c:362:Connecting with protocol version 7.3 net.c:362:Connecting with protocol version 7.2 net.c:362:Connecting with protocol version 7.1 net.c:362:Connecting with protocol version 7.0 net.c:362:Connecting with protocol version 5.0 0020 00 00 00 00 00 00 0b 6b-6f 6d 6d 65 72 7a 00 00 |.......k ommerz..| 0030 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 |........ ........| 0040 00 00 00 00 00 07 00 00-00 00 00 00 00 00 00 00 |........ ........| token.c:422:tds_process_login_tokens() returning TDS_SUCCESS On Wed, 2017-07-05 at 11:44 +0200, Fredy Paquet wrote: > So this issue is also solved, > i will verify correct operation with Sybase 15.7 next weekend. > > Thank you > fp -- 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 Sat Jul 8 11:03:25 2017 From: fredy at opag.ch (Fredy Paquet) Date: Sat, 08 Jul 2017 17:03:25 +0200 Subject: [freetds] FreeTDS 1.1 - missing CS_ROWFMT_RESULT row in ct_results Message-ID: <1499526205.18099.42.camel@opag.ch> Hello Frediano Sorry to bother you again. I'm testing FreeTDS 1.1 (current master branch) with our Sybase ASE 15.7 ctLib application. We found our application to crash after the first SELECT has been issued, returning result rows. Attached there are two TDSDUMP files: ctlib_ok.log - taken with FreeTDS 0.91 ctlib_bad.log - taken with FreeTDS 1.1 If we look at the tds dump, we find that token.c is recognizing the ROWFMT2 result, but doesn't pass correct information back to ct_result() in ct.c (~Line 1215) to process CS_ROWFMT_RESULT. In ctlib_ok.log, you can find ct_res_info() calls after "process_result_tokens returned", but not in ctlib_bad.log. ctlib_ok.log Line 452ff token.c:555:processing result tokens. marker is 61(ROWFMT2) token.c:1740:tds5_process_result mem.c:615:tds_free_all_results() token.c:1764:num_cols=2 token.c:1837:col 0: token.c:1838: column_name=[name] token.c:1844: flags=10 utype=42 type=47 varint=5 token.c:1847: colsize=510 prec=0 scale=0 token.c:1837:col 1: token.c:1838: column_name=[type] token.c:1844: flags=10 utype=1 type=47 varint=5 token.c:1847: colsize=4 prec=0 scale=0 util.c:156:Changed query state from READING to PENDING ct.c:1179:ct_results() process_result_tokens returned 1 (type 4049) ct.c:2346:ct_res_info(0x14285c0, 801, 0x1427c88, -99999, (nil)) ct.c:2346:ct_res_info(0x14285c0, 803, 0x7fff77c3425c, -99999, (nil)) ct.c:2365:ct_res_info(): Number of columns is 2 ctlib_bad.log line 417ff token.c:548:processing result tokens. marker is 61(ROWFMT2) token.c:577:calling tds5_process_result2/1 token.c:1778:tds5_process_result2 mem.c:660:tds_free_all_results() token.c:1802:num_cols=2 token.c:1868:col 0: token.c:1869: column_name=[name] token.c:1875: flags=10 utype=42 type=39 server type 39 varint=1 token.c:1879: colsize=255 prec=0 scale=0 token.c:1868:col 1: token.c:1869: column_name=[type] token.c:1875: flags=10 utype=1 type=47 server type 47 varint=1 token.c:1879: colsize=2 prec=0 scale=0 token.c:1882:tds5_process_result2(): exit mem.c:529:tds_alloc_row() mem.c:565:tds_alloc_row(): SUCCESS token.c:579: tds5_process_result2() = 0 util.c:165:Changed query state from READING to PENDING ct.c:1215:ct_results() process_result_tokens returned 0 (type 4049) token.c:533:tds_process_tokens(0x18bde20, 0x7ffe79e073b8, 0x7ffe79e073bc, 0x6a14) util.c:165:Changed query state from PENDING to READING token.c:548:processing result tokens. marker is ae(CONTROL/FEATUREEXTACK) token.c:132:tds_process_default_tokens() marker is ae(CONTROL/FEATUREEXTACK) token.c:252:Eating CONTROL/FEATUREEXTACK token token.c:548:processing result tokens. marker is a9(ORDERBY) token.c:132:tds_process_default_tokens() marker is a9(ORDERBY) token.c:252:Eating ORDERBY token token.c:548:processing result tokens. marker is d1(ROW) token.c:656:tds_process_tokens::SET_RETURN stopping on current token util.c:165:Changed query state from READING to PENDING ---- The related code change was introduced by the following commit. > Date: 2016-05-01 00:24:32 > Revision: 4fea9e776e5475c4c607b9c2fa85a563e6feb700 > Comment: fix ct-library rows count After experimentally adding the following code segment to the switch, case CS_ROWFMT_RESULT the application doesn't crash anymore processing the results. These lines have been replaced in commit 4fea9. case CS_ROWFMT_RESULT: ... if (context->config.cs_expose_formats) { *result_type = res_type; return CS_SUCCEED; } ... break; Instead of crashing, our application is processing quite a few SELECT results, but starts hanging in ct_fetch() later, when processing a SELECT statements returning 0 rows. Got any ideas about this? fp -- 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: crlib_bad.log Type: text/x-log Size: 26270 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ctlib_ok.log Type: text/x-log Size: 3682541 bytes Desc: not available URL: From campbellg at teds.com Tue Jul 11 11:42:26 2017 From: campbellg at teds.com (Glenn Campbell) Date: Tue, 11 Jul 2017 15:42:26 +0000 Subject: [freetds] can't build dll with gnutls on Windows In-Reply-To: References: Message-ID: I've been pulled off of this project but when/if I get back to it and work out the detailed steps for producing the windows dll via MinGW I'll be sure to post those steps here. Assuming cmake hasn't been updated by then. Thanks for the assistance. On Fri, Jun 9, 2017 at 12:02 PM Glenn Campbell wrote: > The decision to use GnuTLS rather than OpenSSL wasn't a technical one. I'm > working to convince the decision makers in my organization to approve the > use of FreeTDS+OpenSSL. We used GnuTLS several years ago with an old > version of FreeTDS so I don't need approval to use it with the current > version of FreeTDS. But until I get approval to use OpenSSL I'm continuing > to try to get FreeTDS+GnuTLS working. > > I've continued my attempts at building with MinGW and I'm getting a little > further. Here's my current state: > 1) The GnuTLS docs say that it depends on nettle and gmplib so I > downloaded the source for those and did the "./configure make make check > make install" for both of them. No problems there. > 2) I downloaded the source for GnuTLS and when I run "./configure" it told > me that it couldn't find Nettle 3.1. > 3) The first problem appeared to be that my MinGW installation didn't have > pkg-config so I downloaded pkg-config-lite and copied the pkg-config.exe to > the MinGW bin directory. But it still told me that I didn't have Nettle > 3.1. > 4) I set the env variable PKG_CONFIG_PATH to the location where nettle.pc > was located and tried "./configure" again. Then it reported that gmp was > not found. > 5) I set the env variable LDFLAGS to the location where the libgmp.a and > libgmp.la files were located and tried "./configure" again. Then it said > that libtasn1 4.9 wasn't found but I could use --with-included-libtasn1. > 6) I tried "./configure --with-included-libtasn1". Then it said that > libunistring wasn't found but I could use --with-included-unistring. > 7) I tried "./configure --with-included-libtasn1 > --with-included-unistring". Now I get an error that says p11-kit wasn't > found. > > I can keep chasing these problems but it feels like all of this shouldn't > be necessary. Am I missing something in my MinGW installation? Some other > configuration problem? > > I realize that I haven't even gotten to the FreeTDS part of this but any > thoughts or suggestions would be appreciated. > > Thanks in advance. > > On Thu, Jun 8, 2017 at 6:30 AM Frediano Ziglio wrote: > >> 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 >> _______________________________________________ >> FreeTDS mailing list >> FreeTDS at mailman1.ibiblio.org >> http://mailman1.ibiblio.org/mailman/listinfo/freetds >> > From stu at spacehopper.org Mon Jul 10 04:54:25 2017 From: stu at spacehopper.org (Stuart Henderson) Date: Mon, 10 Jul 2017 08:54:25 +0000 (UTC) Subject: [freetds] Update FreeTDS package References: <3e8e899d-e4ee-f206-e922-6c1c16514c5f__48627.7080876336$1498635723$gmane$org@zoznam.sk> Message-ID: On 2017-06-27, LacaK wrote: > FreeTDS has released a new version, 1.0 a year ago, please update freetds package in Debian as well. Updating this will likely need changes to some other packages, these are the ones I ran into when I tried it in OpenBSD: libdbi-drivers: dbd_freetds.c:236: error: 'CS_TDS_80' undeclared (first use in this function) sqsh: cmd_connect.c:864: error: 'CS_TDS_80' undeclared (first use in this function) sybperl: CTlib.xs:659: error: 'CS_BIGDATETIME' undeclared (first use in this function) From freddy77 at gmail.com Mon Jul 17 08:31:05 2017 From: freddy77 at gmail.com (Frediano Ziglio) Date: Mon, 17 Jul 2017 13:31:05 +0100 Subject: [freetds] Update FreeTDS package In-Reply-To: References: <3e8e899d-e4ee-f206-e922-6c1c16514c5f__48627.7080876336$1498635723$gmane$org@zoznam.sk> Message-ID: 2017-07-10 9:54 GMT+01:00 Stuart Henderson : > On 2017-06-27, LacaK wrote: >> FreeTDS has released a new version, 1.0 a year ago, please update freetds package in Debian as well. > > Updating this will likely need changes to some other packages, these are > the ones I ran into when I tried it in OpenBSD: > > libdbi-drivers: > dbd_freetds.c:236: error: 'CS_TDS_80' undeclared (first use in this function) > > sqsh: > cmd_connect.c:864: error: 'CS_TDS_80' undeclared (first use in this function) > > sybperl: > CTlib.xs:659: error: 'CS_BIGDATETIME' undeclared (first use in this function) > Not sure if these was fixed in following 1.00.xx versions. Frediano From no-reply at appveyor.com Sun Jul 30 04:54:23 2017 From: no-reply at appveyor.com (AppVeyor) Date: Sun, 30 Jul 2017 08:54:23 +0000 Subject: [freetds] Build failed: freetds 826 Message-ID: <20170730084917.21321.AD1B38F27D22FA7B@appveyor.com> From fredy at opag.ch Tue Aug 1 09:53:03 2017 From: fredy at opag.ch (Fredy Paquet) Date: Tue, 01 Aug 2017 15:53:03 +0200 Subject: [freetds] FreeTDS 1.1 - missing CS_ROWFMT_RESULT row in ct_results In-Reply-To: <1499526205.18099.42.camel@opag.ch> References: <1499526205.18099.42.camel@opag.ch> Message-ID: <1501595583.4432.24.camel@opag.ch> Hello I need some help on this, brcause i can not completely figure out why it's going wrong. Is there anyone around that fully understands how the tds protocol parser works ? What might be the reason for returning cmd->results_state _CS_RES_RESULTSET_ROWS in an empty rowset ? (see below) fp Steps to reproduce: - roll back commit 4fea9e for testing purpose, is fixing the missing ROWFMT message (actually very few changes, subject to discussion). - the application is hanging in ct_fetch() -> tds_peek() -> tds_get_byte() (gdb) bt #0 0x00007ffff3647e10 in __poll_nocancel () from /lib64/libc.so.6 #1 0x00007ffff461b016 in tds_select (tds=tds at entry=0xc567f0, tds_sel=tds_sel at entry=1, timeout_seconds=) at net.c:621 #2 0x00007ffff461f73a in tds_connection_network (conn=conn at entry=0xc564b0, tds=tds at entry=0xc567f0, send=send at entry=0) at packet.c:378 #3 0x00007ffff4620029 in tds_read_packet (tds=tds at entry=0xc567f0) at packet.c:578 #4 0x00007ffff4605db8 in tds_get_byte (tds=tds at entry=0xc567f0) at read.c:75 #5 0x00007ffff4605df9 in tds_peek (tds=tds at entry=0xc567f0) at read.c:102 #6 0x00007ffff45f0f50 in ct_fetch (cmd=0xc56a40, type=-99999, offset=-99999, option=-99999, prows_read=0xdbf068) at ct.c:1601 #7 0x0000000000452389 in sqlsybcs_nextrow (q=0xc55e70) at sqlsybcs.c:1485 Analysis: ct.c:1210:ct_results() process_result_tokens returned 0 (type 4052) ct.c:1316:ct_results() results state = 1 ct.c:1317:ct_results() command type = 148 ct.c:1318:ct_results() dynamic cmd = 0 ct.c:1340:_CS_RES_RESULTSET_EMPTY command_type 148 ct.c:2366:ct_res_info(0xc56a40, 803, 0xdbee2c, -99999, (nil)) ct.c:2385:ct_res_info(): Number of columns is 1 ct.c:2306:ct_describe(0xc56a40, 1, 0xdbec30) ct.c:1904:_ct_get_client_type(type 52, user 6, size 2) ct.c:2323:ct_describe() datafmt->datatype = 7 server type 52 ct.c:1487:ct_bind(0xc56a40, 1, 0xdbece0, 0xdd01c0, (nil), 0xca1400) ct.c:1489:ct_bind() datafmt count = 1 column_number = 1 ct.c:1548:ct_fetch(0xc56a40, -99999, -99999, -99999, 0xdbf068) ct.c:1210:ct_results() process_result_tokens returned 0 (type 4052) -> returned 0 means TDS_SUCCESS -> type 4052 means res_type is TDS_DONE_RESULT ct.c:1316:ct_results() results state = 1 -> state 1 means _CS_RES_RESULTSET_EMPTY ct.c:1317:ct_results() command type = 148 -> 148 is CS_LANG_CMD If we look at lines following tdsdump_log() in ct.c:1210:ct_results() for(;;) ... case TDS_SUCCESS ... case TDS_DONE_RESULT ... case _CS_RES_RESULTSET_EMPTY we find that this cmd->result_state is always set to _CS_RES_RESULTSET_ROWS which looked **suspicios** to us, with an empty result set? Ater changing the line 1348 in ct.c, as below, our application is no longer hanging and running fine with lots of SQL processing. case _CS_RES_RESULTSET_EMPTY: tdsdump_log( TDS_DBG_FUNC, "_CS_RES_RESULTSET_EMPTY command_type %d\n", cmd->command_type); if (cmd->command_type == CS_CUR_CMD) { *result_type = CS_CURSOR_RESULT; } else { *result_type = CS_ROW_RESULT; } - cmd->results_state = _CS_RES_RESULTSET_ROWS; + cmd->results_state = _CS_RES_CMD_DONE; With the above change, the problem seams to be solved. fp On Sat, 2017-07-08 at 17:03 +0200, Fredy Paquet wrote: > Hello Frediano > > Sorry to bother you again. > > I'm testing FreeTDS 1.1 (current master branch) with our Sybase ASE 15.7 > ctLib application. > > We found our application to crash after the first SELECT has been > issued, returning result rows. > > Attached there are two TDSDUMP files: > > ctlib_ok.log - taken with FreeTDS 0.91 > ctlib_bad.log - taken with FreeTDS 1.1 > > If we look at the tds dump, we find that token.c is recognizing the > ROWFMT2 result, but doesn't pass correct information back to ct_result() > in ct.c (~Line 1215) to process CS_ROWFMT_RESULT. In ctlib_ok.log, you > can find ct_res_info() calls after "process_result_tokens returned", but > not in ctlib_bad.log. > > ctlib_ok.log Line 452ff > > token.c:555:processing result tokens. marker is 61(ROWFMT2) > token.c:1740:tds5_process_result > mem.c:615:tds_free_all_results() > token.c:1764:num_cols=2 > token.c:1837:col 0: > token.c:1838: column_name=[name] > token.c:1844: flags=10 utype=42 type=47 varint=5 > token.c:1847: colsize=510 prec=0 scale=0 > token.c:1837:col 1: > token.c:1838: column_name=[type] > token.c:1844: flags=10 utype=1 type=47 varint=5 > token.c:1847: colsize=4 prec=0 scale=0 > util.c:156:Changed query state from READING to PENDING > ct.c:1179:ct_results() process_result_tokens returned 1 (type 4049) > ct.c:2346:ct_res_info(0x14285c0, 801, 0x1427c88, -99999, (nil)) > ct.c:2346:ct_res_info(0x14285c0, 803, 0x7fff77c3425c, -99999, (nil)) > ct.c:2365:ct_res_info(): Number of columns is 2 > > ctlib_bad.log line 417ff > > token.c:548:processing result tokens. marker is 61(ROWFMT2) > token.c:577:calling tds5_process_result2/1 > token.c:1778:tds5_process_result2 > mem.c:660:tds_free_all_results() > token.c:1802:num_cols=2 > token.c:1868:col 0: > token.c:1869: column_name=[name] > token.c:1875: flags=10 utype=42 type=39 server type 39 varint=1 > token.c:1879: colsize=255 prec=0 scale=0 > token.c:1868:col 1: > token.c:1869: column_name=[type] > token.c:1875: flags=10 utype=1 type=47 server type 47 varint=1 > token.c:1879: colsize=2 prec=0 scale=0 > token.c:1882:tds5_process_result2(): exit > mem.c:529:tds_alloc_row() > mem.c:565:tds_alloc_row(): SUCCESS > token.c:579: tds5_process_result2() = 0 > util.c:165:Changed query state from READING to PENDING > ct.c:1215:ct_results() process_result_tokens returned 0 (type 4049) > token.c:533:tds_process_tokens(0x18bde20, 0x7ffe79e073b8, > 0x7ffe79e073bc, 0x6a14) > util.c:165:Changed query state from PENDING to READING > token.c:548:processing result tokens. marker is > ae(CONTROL/FEATUREEXTACK) > token.c:132:tds_process_default_tokens() marker is > ae(CONTROL/FEATUREEXTACK) > token.c:252:Eating CONTROL/FEATUREEXTACK token > token.c:548:processing result tokens. marker is a9(ORDERBY) > token.c:132:tds_process_default_tokens() marker is a9(ORDERBY) > token.c:252:Eating ORDERBY token > token.c:548:processing result tokens. marker is d1(ROW) > token.c:656:tds_process_tokens::SET_RETURN stopping on current token > util.c:165:Changed query state from READING to PENDING > > ---- > The related code change was introduced by the following commit. > > > Date: 2016-05-01 00:24:32 > > Revision: 4fea9e776e5475c4c607b9c2fa85a563e6feb700 > > Comment: fix ct-library rows count > > After experimentally adding the following code segment to the switch, > case CS_ROWFMT_RESULT the application doesn't crash anymore processing > the results. These lines have been replaced in commit 4fea9. > > case CS_ROWFMT_RESULT: > ... > if (context->config.cs_expose_formats) { > *result_type = res_type; > return CS_SUCCEED; > } > ... > break; > > Instead of crashing, our application is processing quite a few SELECT > results, but starts hanging in ct_fetch() later, when processing a > SELECT statements returning 0 rows. > > Got any ideas about this? > fp > -- 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: smime.p7s Type: application/x-pkcs7-signature Size: 3480 bytes Desc: not available URL: From fredy at opag.ch Wed Aug 2 06:13:00 2017 From: fredy at opag.ch (Fredy Paquet) Date: Wed, 02 Aug 2017 12:13:00 +0200 Subject: [freetds] FreeTDS 1.1 - missing CS_ROWFMT_RESULT row in ct_results In-Reply-To: <1501595583.4432.24.camel@opag.ch> References: <1499526205.18099.42.camel@opag.ch> <1501595583.4432.24.camel@opag.ch> Message-ID: <1501668780.3912.4.camel@opag.ch> The problem with _CS_RES_RESULTSET_ROWS was introduced by commit 4a8e777 on May 11 2016: Author: Frediano Ziglio Date: 2016-05-11 21:37:04 Revision: 4a8e777feb343395ee2e163a55708f783386b5fe Comment: fix CT-library compute columns Due to "fix ct-library rows count" commit compute rows were returned as CS_ROW_RESULT instead of CS_COMPUTE_RESULT. This caused application to use normal row data instead of compute one. Signed-off-by: Frediano Ziglio On Tue, 2017-08-01 at 15:53 +0200, Fredy Paquet wrote: > Hello > > I need some help on this, brcause i can not completely figure out why > it's going wrong. > > Is there anyone around that fully understands how the tds protocol > parser works ? > > What might be the reason for returning cmd->results_state > _CS_RES_RESULTSET_ROWS in an empty rowset ? (see below) > > fp > > Steps to reproduce: > - roll back commit 4fea9e for testing purpose, is fixing the missing > ROWFMT message (actually very few changes, subject to discussion). > > - the application is hanging in ct_fetch() -> tds_peek() -> > tds_get_byte() > > (gdb) bt > #0 0x00007ffff3647e10 in __poll_nocancel () from /lib64/libc.so.6 > #1 0x00007ffff461b016 in tds_select (tds=tds at entry=0xc567f0, > tds_sel=tds_sel at entry=1, timeout_seconds=) at > net.c:621 > #2 0x00007ffff461f73a in tds_connection_network > (conn=conn at entry=0xc564b0, > tds=tds at entry=0xc567f0, send=send at entry=0) at packet.c:378 > #3 0x00007ffff4620029 in tds_read_packet (tds=tds at entry=0xc567f0) > at packet.c:578 > #4 0x00007ffff4605db8 in tds_get_byte (tds=tds at entry=0xc567f0) at > read.c:75 > #5 0x00007ffff4605df9 in tds_peek (tds=tds at entry=0xc567f0) at > read.c:102 > #6 0x00007ffff45f0f50 in ct_fetch (cmd=0xc56a40, type=-99999, > offset=-99999, > option=-99999, prows_read=0xdbf068) at ct.c:1601 > #7 0x0000000000452389 in sqlsybcs_nextrow (q=0xc55e70) at > sqlsybcs.c:1485 > > Analysis: > > ct.c:1210:ct_results() process_result_tokens returned 0 (type 4052) > ct.c:1316:ct_results() results state = 1 > ct.c:1317:ct_results() command type = 148 > ct.c:1318:ct_results() dynamic cmd = 0 > ct.c:1340:_CS_RES_RESULTSET_EMPTY command_type 148 > ct.c:2366:ct_res_info(0xc56a40, 803, 0xdbee2c, -99999, (nil)) > ct.c:2385:ct_res_info(): Number of columns is 1 > ct.c:2306:ct_describe(0xc56a40, 1, 0xdbec30) > ct.c:1904:_ct_get_client_type(type 52, user 6, size 2) > ct.c:2323:ct_describe() datafmt->datatype = 7 server type 52 > ct.c:1487:ct_bind(0xc56a40, 1, 0xdbece0, 0xdd01c0, (nil), 0xca1400) > ct.c:1489:ct_bind() datafmt count = 1 column_number = 1 > ct.c:1548:ct_fetch(0xc56a40, -99999, -99999, -99999, 0xdbf068) > > ct.c:1210:ct_results() process_result_tokens returned 0 (type 4052) > -> returned 0 means TDS_SUCCESS > -> type 4052 means res_type is TDS_DONE_RESULT > > ct.c:1316:ct_results() results state = 1 > -> state 1 means _CS_RES_RESULTSET_EMPTY > > ct.c:1317:ct_results() command type = 148 > -> 148 is CS_LANG_CMD > > If we look at lines following tdsdump_log() in ct.c:1210:ct_results() > for(;;) > ... > case TDS_SUCCESS > ... > case TDS_DONE_RESULT > ... > case _CS_RES_RESULTSET_EMPTY > > we find that this cmd->result_state is always set to > _CS_RES_RESULTSET_ROWS which looked **suspicios** to us, with an empty > result set? > > Ater changing the line 1348 in ct.c, as below, our application is no > longer hanging and running fine with lots of SQL processing. > > case _CS_RES_RESULTSET_EMPTY: > tdsdump_log( > TDS_DBG_FUNC, > "_CS_RES_RESULTSET_EMPTY command_type %d\n", > cmd->command_type); > > if (cmd->command_type == CS_CUR_CMD) { > *result_type = CS_CURSOR_RESULT; > } else { > *result_type = CS_ROW_RESULT; > } > - cmd->results_state = _CS_RES_RESULTSET_ROWS; > + cmd->results_state = _CS_RES_CMD_DONE; > > With the above change, the problem seams to be solved. > > fp > > On Sat, 2017-07-08 at 17:03 +0200, Fredy Paquet wrote: > > Hello Frediano > > > > Sorry to bother you again. > > > > I'm testing FreeTDS 1.1 (current master branch) with our Sybase ASE 15.7 > > ctLib application. > > > > We found our application to crash after the first SELECT has been > > issued, returning result rows. > > > > Attached there are two TDSDUMP files: > > > > ctlib_ok.log - taken with FreeTDS 0.91 > > ctlib_bad.log - taken with FreeTDS 1.1 > > > > If we look at the tds dump, we find that token.c is recognizing the > > ROWFMT2 result, but doesn't pass correct information back to ct_result() > > in ct.c (~Line 1215) to process CS_ROWFMT_RESULT. In ctlib_ok.log, you > > can find ct_res_info() calls after "process_result_tokens returned", but > > not in ctlib_bad.log. > > > > ctlib_ok.log Line 452ff > > > > token.c:555:processing result tokens. marker is 61(ROWFMT2) > > token.c:1740:tds5_process_result > > mem.c:615:tds_free_all_results() > > token.c:1764:num_cols=2 > > token.c:1837:col 0: > > token.c:1838: column_name=[name] > > token.c:1844: flags=10 utype=42 type=47 varint=5 > > token.c:1847: colsize=510 prec=0 scale=0 > > token.c:1837:col 1: > > token.c:1838: column_name=[type] > > token.c:1844: flags=10 utype=1 type=47 varint=5 > > token.c:1847: colsize=4 prec=0 scale=0 > > util.c:156:Changed query state from READING to PENDING > > ct.c:1179:ct_results() process_result_tokens returned 1 (type 4049) > > ct.c:2346:ct_res_info(0x14285c0, 801, 0x1427c88, -99999, (nil)) > > ct.c:2346:ct_res_info(0x14285c0, 803, 0x7fff77c3425c, -99999, (nil)) > > ct.c:2365:ct_res_info(): Number of columns is 2 > > > > ctlib_bad.log line 417ff > > > > token.c:548:processing result tokens. marker is 61(ROWFMT2) > > token.c:577:calling tds5_process_result2/1 > > token.c:1778:tds5_process_result2 > > mem.c:660:tds_free_all_results() > > token.c:1802:num_cols=2 > > token.c:1868:col 0: > > token.c:1869: column_name=[name] > > token.c:1875: flags=10 utype=42 type=39 server type 39 varint=1 > > token.c:1879: colsize=255 prec=0 scale=0 > > token.c:1868:col 1: > > token.c:1869: column_name=[type] > > token.c:1875: flags=10 utype=1 type=47 server type 47 varint=1 > > token.c:1879: colsize=2 prec=0 scale=0 > > token.c:1882:tds5_process_result2(): exit > > mem.c:529:tds_alloc_row() > > mem.c:565:tds_alloc_row(): SUCCESS > > token.c:579: tds5_process_result2() = 0 > > util.c:165:Changed query state from READING to PENDING > > ct.c:1215:ct_results() process_result_tokens returned 0 (type 4049) > > token.c:533:tds_process_tokens(0x18bde20, 0x7ffe79e073b8, > > 0x7ffe79e073bc, 0x6a14) > > util.c:165:Changed query state from PENDING to READING > > token.c:548:processing result tokens. marker is > > ae(CONTROL/FEATUREEXTACK) > > token.c:132:tds_process_default_tokens() marker is > > ae(CONTROL/FEATUREEXTACK) > > token.c:252:Eating CONTROL/FEATUREEXTACK token > > token.c:548:processing result tokens. marker is a9(ORDERBY) > > token.c:132:tds_process_default_tokens() marker is a9(ORDERBY) > > token.c:252:Eating ORDERBY token > > token.c:548:processing result tokens. marker is d1(ROW) > > token.c:656:tds_process_tokens::SET_RETURN stopping on current token > > util.c:165:Changed query state from READING to PENDING > > > > ---- > > The related code change was introduced by the following commit. > > > > > Date: 2016-05-01 00:24:32 > > > Revision: 4fea9e776e5475c4c607b9c2fa85a563e6feb700 > > > Comment: fix ct-library rows count > > > > After experimentally adding the following code segment to the switch, > > case CS_ROWFMT_RESULT the application doesn't crash anymore processing > > the results. These lines have been replaced in commit 4fea9. > > > > case CS_ROWFMT_RESULT: > > ... > > if (context->config.cs_expose_formats) { > > *result_type = res_type; > > return CS_SUCCEED; > > } > > ... > > break; > > > > Instead of crashing, our application is processing quite a few SELECT > > results, but starts hanging in ct_fetch() later, when processing a > > SELECT statements returning 0 rows. > > > > Got any ideas about this? > > fp > > > > _______________________________________________ > 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: smime.p7s Type: application/x-pkcs7-signature Size: 3480 bytes Desc: not available URL: From no-reply at appveyor.com Mon Sep 18 08:43:07 2017 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 18 Sep 2017 12:43:07 +0000 Subject: [freetds] Build failed: freetds 906 Message-ID: <20170918123742.121463.852ACFF715618C98@appveyor.com> From no-reply at appveyor.com Mon Sep 18 09:20:46 2017 From: no-reply at appveyor.com (AppVeyor) Date: Mon, 18 Sep 2017 13:20:46 +0000 Subject: [freetds] Build completed: freetds 907 Message-ID: <20170918132030.73642.A2165699F62774C0@appveyor.com>