Re: Sybase Connection - trouble without protocol fallback
Fredy Paquet <[email protected]> Wed, 28 Jun 2017 09:50:07 +0200
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Organization | OPAG Informatik AG |
| Message-ID | <[email protected]> |
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 <[email protected]>: > > > 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 _______________________________________________ FreeTDS mailing list [email protected] https://lists.ibiblio.org/mailman/listinfo/freetds