FreeTDS Development Group

["James K. Lowden" <jklowden AT freetds.org>]

Hi Kevin, 

My guess is one of these:

1.  your server is not set to accept TCP/IP connections, or 
2.  is not really listening on port 5000, or
3.  a firewall is interfering, or
4.  something we've never seen.  

The fact that you can't even get a 4.2 connection to work, despite
seemingly using the right address and port, is decidedly odd.  

> 1: according the ODBC that does connect to the server the version is  
> 2000.86.3959.00

OK.  That's a little *too* precise, but I take it we're talking to
Microsoft SQL Server 2000.  (If you mentioned vendor or version before, I
missed it.) 

> 2. set TDSVER to 8.0 according to this
> page(http://www.freetds.org/userguide/freetdsconf.htm#FREETDSCONFPURPOSE
> 
> ) statement of MSQL 2000 being set to 8.0

Fine.  7.0 would do, too.  

> log.c:190:Starting log file for FreeTDS 0.82
>          on 2009-01-07 12:16:42 with debug flags 0x4fff.

Good, we're using the current release. 

> net.c:210:Connecting to [ip address removed] port 5000 (TDS version 8.0)

Port 5000 is peculiar, because it's the compiled-in default (for Sybase
servers) unless you used the --with-tdsver configure option.  I would
double and triple check that's what the server is configured to use. 
(http://msdn.microsoft.com/en-us/library/aa197971(SQL.80).aspx) I would
also double-check my Win32 ODBC DSN.  

That said, I'm inclined to believe you.  Although it is possible something
else is listening on that port, the behavior is exactly what we see from a
server that gets a bad login packet.  More below. 

> net.c:303:tds_open_socket() succeeded

Connected. 

> login.c:735:quietly sending TDS 7+ login packet
> token.c:312:tds_process_login_tokens()
> util.c:334:tdserror(0x100270, 0x100710, 20017, 0)

$ grep 20017 include/sybdb.h
#define SYBESEOF        20017   /* Unexpected EOF from SQL Server. */

The server closed the connection.  That's what it does when it detects a
protocol violation.  

If connected to, say, an ftp or smtp port by mistake (not that 5000
usually used for that purpose) tsql times out waiting for an answer. 
Webservers OTOH mimic the behavior because HTTP drops the connection after
every request.  

One thing it's not: encryption.  For an example of a failed encrypted
connection, cf. http://jeremy.kister.net/tmp/tdsdump-0.82.txt.  

HTH.  Let us know how it goes.  

--jkl