FreeTDS Development Group

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

Hugo Barbosa <hugo.barbosa AT gmail.com> wrote:
> 
> I'm using FreeTDS 0.62 and Fedora Core 2, trying to connect to MS SQL
> Server 8.0 in Windows 2000. 
...
> Msg 20004, Level 9, State 0, Server OpenClient, Line 0
> Read from SQL server failed.
...
> The same message is returned if I use "-S server_name" or "-H
> host_name -p port".
...
> Starting log file for FreeTDS 0.62.4
>         on 2004-12-10 08:55:20 with debug level 99.
...
> 08:55:20.282173 Connecting to 10.11.120.83 port 3389, TDS 8.0.
...
> 08:55:20.282867 tds_process_login_tokens()
> 08:56:20.287728 goodread: errno=104, "Connection reset by peer"
> 08:56:20.287809 tds_client_msg: #20004: "Read from SQL server
> failed.".  Connection state is now 0.

As you surmised, "Connection reset by peer" is your trouble.  It's not an
authentication problem, though.  If it were, the server wouldn't just drop
the connection; it's not that rude.  It would return a rejection message. 


Hmm. I should write that down somewhere: In a TDSDUMP log, authentication
problems always show a packet coming back from the server.  

Is the server definitely listening for TCP/IP connections, and not just
named pipes?  (I don't know if such a setup would answer to telnet
connections.)  Using Microsoft's tools, can a TCP/IP client connect?  

Is there any chance that the server isn't actually listening on 3389, but
something else is?  Is there an intervening firewall?  

You might try TDSVER = 7.0 or TDSVER = 4.2.  Beware 4.2 will expose the
login packet to the TDSDUMP log.  

FreeTDS definitely knows how to connect to SQL Server 2000.  The fact that
the connection is abruptly dropped leads me to think its a low-level
communications setup issue.  

--jkl