Skip to Content.
Sympa Menu

freetds - Re: [freetds] Sybase Connection - trouble without protocol fallback

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Fredy Paquet <fredy AT opag.ch>
  • To: Frediano Ziglio <freddy77 AT gmail.com>
  • Cc: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Sybase Connection - trouble without protocol fallback
  • Date: Wed, 28 Jun 2017 09:12:15 +0200

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





Archive powered by MHonArc 2.6.24.

Top of Page