FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2017-06-28 10:48 GMT+01:00 Fredy Paquet <fredy AT opag.ch>:
> 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 <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
>