Skip to Content.
Sympa Menu

freetds - [freetds] 0xE2 (capability) server response type

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frank Chung <chungf AT ha.org.hk>
  • To: <freetds AT lists.ibiblio.org>
  • Cc:
  • Subject: [freetds] 0xE2 (capability) server response type
  • Date: Mon, 16 Feb 2004 15:50:29 +0800

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




Archive powered by MHonArc 2.6.24.

Top of Page