FreeTDS Development Group

[Fredy Paquet <fredy AT 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 <fredy AT 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?
> > >
> > 
> > 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