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: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Cc: Frediano Ziglio <freddy77 AT gmail.com>
  • Subject: Re: [freetds] Sybase Connection - trouble without protocol fallback
  • Date: Wed, 28 Jun 2017 11:48:54 +0200

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.

fp

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 <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