FreeTDS Development Group

[Frank Chung <chungf AT ha.org.hk>]

Dear all,

I'm having a hard time getting FreeTDS to work with Sybase 11.5. I'm using
the Debian unstable package for FreeTDS (which is version 0.61) but I
believe the same problem holds true for v0.62.

When I connect to the server with sqsh, the login is authenticated
successfully but sqsh just sits there without giving me the "1>" prompt,
until I press ^C. After that, everything (select, insert, and update
queries) works fine. If instead of sqsh I'm connecting through a
non-interactive process (e.g. PHP script with sybase-ct support), the
process would wait indefinitely until killed.

This is how a sqsh session looks like:

-----
# sqsh -S DATABASEXXX -U USERXXXX -P PASSWORDXXXX
sqsh-2.1 Copyright (C) 1995-2001 Scott C. Gray
This is free software with ABSOLUTELY NO WARRANTY
For more information type '\warranty'
^C   <-- *** The process hangs here until I press ^C ***
1> select * from COLOR where 1=0
2> go
(0 rows affected)
1> \quit
#
-----

The freetds.log resulting from this session is as follows:

-----
Starting log file with debug level 99.
2004-02-16 14:48:40.117334 iconv will convert client-side data to the 
"iso-8859-1" character set
2004-02-16 14:48:40.139150 Connecting addr 188.19.7.231 port 20002 with TDS 
version 5.0
Sending packet @ 2004-02-16 14:48:40.139998
0000  02 00 02 00 00 00 00 00  xx xx xx xx xx xx xx xx   |........ HOSTNAME|
0010  xx xx xx xx xx xx xx xx  xx xx xx xx xx xx xx 00   |XXXXXXXX XXXXXXX.|
0020  00 00 00 00 00 00 17 xx  xx xx xx xx xx xx xx 00   |.......U SERXXXX.|
0030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0040  00 00 00 00 00 08 xx xx  xx xx xx xx xx xx xx xx   |......PA SSWORDXX|
0050  xx xx 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |XX...... ........|
0060  00 00 00 00 0c 33 37 38  37 36 00 00 00 00 00 00   |.....378 76......|
0070  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0080  00 00 00 05 03 01 06 0a  09 01 00 00 00 00 00 00   |........ ........|
0090  00 00 00 00 73 71 73 68  00 00 00 00 00 00 00 00   |....sqsh ........|
00a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
00b0  00 00 04 xx xx xx xx xx  xx xx xx xx xx xx 00 00   |...DATAB ASEXXX..|
00c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
00d0  00 0b 00 0c xx xx xx xx  xx xx xx xx xx xx xx xx   |....PASS WORDXXXX|
00e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
00f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0100  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0120  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0130  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0140  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0150  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0170  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0180  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
0190  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
01a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
01b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
01c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |........ ........|
01d0  00 0e 05 00 00 00 43 54  2d 4c 69 62 72 61 72 79   |......CT -Library|
01e0  0a 05 00 00 00 00 0d 11  75 73 5f 65 6e 67 6c 69   |........ us_engli|
01f0  73 68 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |sh...... ........|

Sending packet @ 2004-02-16 14:48:40.141298
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|
0020  5f 31 00 00 00 00 00 00  00 00 00 00 00 00 00 00   |_1...... ........|
0030  00 00 00 00 00 00 00 00  00 00 00 05 01 35 31 32   |........ .....512|
0040  00 00 00 03 00 00 00 00  e2 16 00 01 09 00 00 06   |........ ........|
0050  6d 7f ff ff ff fe 02 09  00 00 00 00 0a 68 00 00   |m....... .....h..|
0060  00                                                 |.|

2004-02-16 14:48:40.141605 inside tds_process_login_tokens()
Received header @ 2004-02-16 14:48:40.217653
0000  04 01 00 fa 00 00 00 00                            |........|

Received packet @ 2004-02-16 14:48:40.217776
0000  e3 0d 00 03 05 69 73 6f  5f 31 05 63 70 38 35 30   |.....iso _1.cp850|
0010  e5 51 00 48 16 00 00 01  0a 05 5a 5a 5a 5a 5a 00   |.Q.H.... ..ZZZZZ.|
0020  01 00 31 00 43 68 61 6e  67 65 64 20 63 6c 69 65   |..1.Chan ged clie|
0030  6e 74 20 63 68 61 72 61  63 74 65 72 20 73 65 74   |nt chara cter set|
0040  20 73 65 74 74 69 6e 67  20 74 6f 20 27 69 73 6f   | setting  to 'iso|
0050  5f 31 27 2e 0a 0b xx xx  xx xx xx xx xx xx xx xx   |_1'...DA TABASEXX|
0060  xx 00 01 00 e3 0c 00 01  03 xx xx xx 06 6d 61 73   |X....... .DBX.mas|
0070  74 65 72 e5 43 00 45 16  00 00 02 0a 05 5a 5a 5a   |ter.C.E. .....ZZZ|
0080  5a 5a 00 01 00 23 00 43  68 61 6e 67 65 64 20 64   |ZZ...#.C hanged d|
0090  61 74 61 62 61 73 65 20  63 6f 6e 74 65 78 74 20   |atabase  context |
00a0  74 6f 20 27 xx xx xx 27  2e 0a 0b xx xx xx xx xx   |to 'DBX' ...DATAB|
00b0  xx xx xx xx xx xx 00 01  00 e3 06 00 04 03 35 31   |ASEXXX.. ......51|
00c0  32 00 ad 14 00 05 05 00  00 00 0a 73 71 6c 20 73   |2....... ...sql s|
00d0  65 72 76 65 72 0b 05 01  00 e2 16 00 01 00 02 09   |erver... ........|
00e0  00 00 00 00 02 00 00 00  00 fd 00 00 02 00 d3 00   |........ ........|
00f0  00 00                                              |..|

2004-02-16 14:48:40.218353 inside tds_process_default_tokens() marker is 
e3(ENVCHANGE)
2004-02-16 14:48:40.218463 inside tds_process_default_tokens() marker is 
e5(EED)
2004-02-16 14:48:40.218569 inside tds_process_default_tokens() marker is 
e3(ENVCHANGE)
2004-02-16 14:48:40.218633 inside tds_process_default_tokens() marker is 
e5(EED)
2004-02-16 14:48:40.218707 inside tds_process_default_tokens() marker is 
e3(ENVCHANGE)
2004-02-16 14:48:40.218770 inside tds_process_default_tokens() marker is 
e2(CAPABILITY)
( *** I waited 20 seconds or so, then pressed ^C here. Note timestamps. ***)
2004-02-16 14:49:05.497391 inside ct_cmd_alloc()
2004-02-16 14:49:05.497494 inside ct_command()
2004-02-16 14:49:05.497553 inside ct_cmd_props() action = CS_GET property = 51
2004-02-16 14:49:05.497631 inside ct_send()
Sending packet @ 2004-02-16 14:49:05.497731
0000  0f 01 00 2c 00 00 00 00  21 1f 00 00 00 00 73 65   |...,.... !.....se|
0010  6c 65 63 74 20 2a 20 66  72 6f 6d 20 43 4f 4c 4f   |lect * f rom COLO|
0020  52 20 77 68 65 72 65 20  31 3d 30 0a               |R where  1=0.|
( *** Everything looks normal beyond this point. ***)
( *** snip ***)
-----

It looks like after the 0xE2 (capability) response (at timestamp
14:48:40.218770), FreeTDS was expecting the 0xFD (done) marker, while the
server has already sent all it has to send, so the client just sits there.

This is the 0xE2 marker just before the client hangs:
-----
00d0  -- -- -- -- -- -- -- --  -- e2 16 00 01 00 02 09   |-------- -.......|
00e0  00 00 00 00 02 00 00 00  00 fd 00 00 02 00 d3 00   |........ ........|
00f0  00 00                                              |..|
-----

>From empirical observation, it sure looks like that the 0xE2 response is
just 16 bytes long, and then the "FD 00 00 02 00 D3 00 00 00" sequence is
actually a 0xFD response.

Searching through the mailing list archives for 0xE2 responses from other
people's logs, I observed something interesting: They all have the sequence
"E2 16 00 01 09 (9 bytes of stuff) 02 09 (9 bytes of stuff)". (Some start
with "E2 00 16" -- but this might just be an endian thing.)

Compare this with my 0xE2 response, which starts with "E2 16 00 01 00"
intead of "E2 16 00 01 *09*".

Could it be that the "16 00" in an 0xE2 response isn't meant to be the
packet length, as in most other responses? (In fact, *all* 0xE2 reponses
gleaned from the web so far start with "E2 16 00" or "E2 00 16".) Could the
"01 09" that follows means there are 9 bytes of "type 01" data), and then
"02 09" means 9 bytes of "type 02" data? This interpretation would fit my E2
header perfectly (0 bytes of "type 01" data followed by 9 bytes of "type 02"
data, followed by a 0xFD response).

Has anyone encountered this before? Is there any quick fix I can apply,
either on the client-side or on the server? Any enlightenment will be much
appreciated.

Thanks and Regards,
Frank