Re: Sybase Connection - trouble without protocol fallback
Frediano Ziglio <[email protected]> Mon, 3 Jul 2017 19:04:33 +0100
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <CAHt6W4eJaevCuUu2d+Unz9HwfqKBQV2bwASN23f-5N9NX9zPow@mail.gmail.com> |
2017-06-28 10:48 GMT+01:00 Fredy Paquet <[email protected]>: > 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 <[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