Skip to Content.
Sympa Menu

freetds - Re: via PHP to Microsoft SQL Server V7.0

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: James Cameron <james.cameron AT compaq.com>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: via PHP to Microsoft SQL Server V7.0
  • Date: Tue, 18 Jan 2000 14:19:24 +1100


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)




Archive powered by MHonArc 2.6.24.

Top of Page