Troubleshooting FreeTDS Connection Errors (Error 20002) to MS SQL Server from Linux


2 views

When attempting to connect to MS SQL Server 2014 from RHEL 7 using FreeTDS, you're encountering two distinct error patterns:

// Without credentials
Error 20002: Adaptive Server connection failed

// With credentials
Error 20017: Unexpected EOF from the server
Error 20002: Adaptive Server connection failed

The telnet test confirms network connectivity to port 1433, and the Windows ODBC connection works, which helps narrow down potential causes:

// Successful network test
$ telnet my.server.address 1433
Trying 11.22.33.444...
Connected to my.server.address.

Your current freetds.conf shows:

[global]
  tds version = 7.0

[MYSERVER]
  host = my.server.address
  port = 1433
  tds version = 7.0

The TDSDUMP log reveals crucial authentication details:

gssapi.c:218:using kerberos name MSSQLSvc/my.server.address:1433
gssapi.c:334:gss_init_sec_context: min_stat 2529639136 "Unknown error -1765328160"
gssapi.c:374:gss_init_sec_context: GSS_S_FAILURE
login.c:472:login packet rejected

Based on the error patterns, here are recommended troubleshooting steps:

// First, test with explicit credentials and verbose output
$ TDSDUMP=/tmp/freetds.log tsql -S MYSERVER -U myusername -P mypassword -v

// Alternative TDS version configuration
[MYSERVER]
  host = my.server.address
  port = 1433
  tds version = 7.3
  client charset = UTF-8
  encrypt = false

For more stubborn connection issues, consider these additional parameters:

[MYSERVER]
  host = my.server.address
  port = 1433
  tds version = 7.3
  client charset = UTF-8
  encrypt = false
  auth = ntlmv2
  use ntlmv2 = yes
  domain = YOURDOMAIN

To verify the SQL Server is properly advertising itself:

// Check SQL Server browser service (if using dynamic ports)
$ nmap -sU -p 1434 my.server.address

// Test raw TDS protocol response
$ echo -e "\x02" | nc my.server.address 1433 | hexdump -C

If FreeTDS continues to fail, consider these workarounds:

// Using isql (unixODBC)
$ isql -v MYSERVER myusername mypassword

// Python alternative with pyodbc
import pyodbc
conn = pyodbc.connect(
    'DRIVER={FreeTDS};SERVER=my.server.address;PORT=1433;'
    'DATABASE=mydb;UID=myusername;PWD=mypassword'
)

Remember to check your SQL Server logs simultaneously during connection attempts to correlate any authentication failures.


When attempting to connect to MS SQL Server 2014 from RHEL 7 using FreeTDS, you might encounter two distinct error patterns:


# Without credentials
Error 20002 (severity 9):
        Adaptive Server connection failed

# With credentials  
Error 20017 (severity 9):
        Unexpected EOF from the server
Error 20002 (severity 9):
        Adaptive Server connection failed

Based on the TDSDUMP log output, the key failure occurs during GSS authentication:


gssapi.c:334:gss_init_sec_context: min_stat 2529639136 "Unknown error -1765328160"
gssapi.c:374:gss_init_sec_context: GSS_S_FAILURE: The routine failed for reasons that are not defined at the GSS level.
login.c:472:login packet rejected

First verify network-level connectivity:


telnet my.server.address 1433
nc -zv my.server.address 1433

If these succeed but FreeTDS fails, we're dealing with an authentication protocol issue rather than network connectivity.

Modify your /etc/freetds.conf with these critical parameters:


[MYSERVER]
    host = my.server.address
    port = 1433
    tds version = 7.4
    client charset = UTF-8
    # Disable GSS/Kerberos if not needed
    use ntlmv2 = yes
    use krb5 = no

If Kerberos isn't required, try forcing NTLM authentication:


tsql -S MYSERVER -U myusername -P mypassword -o "use ntlmv2=yes"

For SQL Server authentication specifically:


tsql -S MYSERVER -U myusername -P mypassword -o "use ntlmv2=no"

Enable verbose logging before attempting connections:


export TDSDUMP=/tmp/freetds.log
export TDSDUMPCONFIG=/tmp/freetds_config.log
tsql -S MYSERVER -U myusername -P mypassword

SQL Server 2014 works best with TDS 7.3 or 7.4. Try these versions:


# In freetds.conf
tds version = 7.3
# OR
tds version = 7.4

Validate your configuration with alternative tools:


# Using sqsh
sqsh -S MYSERVER -U myusername -P mypassword

# Using bsqldb
bsqldb -c "server=MYSERVER;username=myusername;password=mypassword"

Even though telnet works, ensure all required ports are open:


# For named instances
udp/1434 

# For AlwaysOn availability groups
tcp/5022

If you must use Kerberos authentication:


kinit myusername@MYREALM.COM
kvno MSSQLSvc/my.server.address:1433

Verify your /etc/krb5.conf contains correct realm and domain settings.

After making changes, test with verbose output:


tsql -C # Verify FreeTDS version
tsql -S MYSERVER -U myusername -P mypassword -o "tds version=7.4"

Successful connection should display the SQL Server version and prompt change.