via PHP to Microsoft SQL Server V7.0
james.cameron at compaq.com
Mon Jan 17 22:19:24 EST 2000
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
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
#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
#4 0x40015249 in tds_connect (login=0x80d0f40) at login.c:140
#5 0x4000fa57 in dbopen (login=0x80d0f30, server=0x80d0d30 "giskard")
#6 0x807a6ca in php3_sybase_do_connect (ht=0x80d0cc8,
list=0x80bb3d0, plist=0x80bb3a4, persistent=0) at
#7 0x807a816 in php3_sybase_connect (ht=0x80d0cc8,
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
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
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
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
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)
More information about the FreeTDS