FreeTDS Development Group

[James Cameron <james.cameron AT compaq.com>]

Well, I've got a connection going out, but the other end drops it.
Any ideas for the possible causes?  Can the TDS protocol be echoed by a
TCP relay?  Or does it contain the IP address of the client?

(Note: I do not administer the other end, and I am doing this access
without specific permission.  I do have the ability to access their
database via a client they provide, but it only runs on Microsoft
Windows so I end up using a remote window session to get at it.  My task
is to provide a platform independent web interface to the data on the
server.)

Configuration: nestor is a 486/100 running the php3 and freetds code. 
idda is a relaying host, accepting connections on port 1433 and
transferring them to the actual Microsoft SQL Server over a tunnel
running on 56k modem.

When the php script runs, it stalls within the sybase_connect() while
the connection is made.  However the connection is closed by the server,
and the message "Unknown marker: 0!!" is displayed.  The php script
stalls at this point.  Attaching gdb to the process shows the following
stack trace;

#0  0x400f66f4 in __read ()
#1  0x4001adf4 in __DTOR_END__ ()
#2  0x40015d72 in tds_get_byte (tds=0x80d20a0) at read.c:35
#3  0x40012d7e in tds_process_login_tokens (tds=0x80d20a0) at
token.c:157
#4  0x40015249 in tds_connect (login=0x80d0f40) at login.c:140
#5  0x4000fa57 in dbopen (login=0x80d0f30, server=0x80d0d30 "giskard")
    at dblib.c:441
#6  0x807a6ca in php3_sybase_do_connect (ht=0x80d0cc8,
return_value=0x80aa4b0, 
    list=0x80bb3d0, plist=0x80bb3a4, persistent=0) at
functions/sybase.c:468
#7  0x807a816 in php3_sybase_connect (ht=0x80d0cc8,
return_value=0x80aa4b0, 
    list=0x80bb3d0, plist=0x80bb3a4) at functions/sybase.c:519
#8  0x8053700 in phpparse () at control_structures_inline.h:929
#9  0x8059f66 in php3_parse (yyin=0x80cb8f8) at main.c:1538
#10 0x805a706 in main (argc=2, argv=0xbffffd74) at main.c:1829

It appears the code may not know how to handle premature disconnection.
There is apparently no timeout.

The network trace looks like this;

13:49:06.297887 nestor.1261 > idda.1433: S 1966472028:1966472028(0) win
32120 <mss 1460,sackOK,timestamp 2039198 0,nop,wscale 0> (DF)
13:49:06.297887 idda.1433 > nestor.1261: S 4294966272:4294966272(0) ack
1966472029 win 33580 <mss 1460,nop,wscale 0> (DF)
13:49:06.297887 nestor.1261 > idda.1433: . ack 1 win 32120 (DF)
13:49:06.297887 nestor.1261 > idda.1433: P 1:513(512) ack 1 win 32120
(DF)
13:49:06.357857 idda.1433 > nestor.1261: . ack 513 win 33068 (DF)
13:49:06.357857 nestor.1261 > idda.1433: P 513:606(93) ack 1 win 32120
(DF)
13:49:06.457807 idda.1433 > nestor.1261: . ack 606 win 32975 (DF)
13:49:09.146879 idda.1433 > nestor.1261: F 1:1(0) ack 606 win 32975 (DF)
13:49:09.146879 nestor.1261 > idda.1433: . ack 2 win 32120 (DF)
13:49:09.146879 nestor.1261 > idda.1433: F 606:606(0) ack 2 win 32120
(DF)
13:49:09.146879 idda.1433 > nestor.1261: . ack 607 win 32974 (DF)

The interfaces file points at idda, which is 10.0.0.4

# cat $SYBASE/interfaces
giskard
        query tcp ether 10.0.0.4 1433
        master tcp ether 10.0.0.4 1433

Does the name in the interfaces file have to match the name the server
believes it to be?

-- 
James Cameron                                      (cameron AT stl.dec.com)