Unexpected EOF when connecting to server from Ubuntu LTS 20.04

[jeffkirk1]

I compiled both the current stable and nightly release (as of April 28, 2020) versions of FreeTDS successfully. I attempted to login to a Microsoft SQL Server with the following command line (real IP addresses and credentials replaced with variables) and got an error:

ubuntu_lts_20_04 $ tsql -H $SERVER_IP -p 2001 -U $USERNAME -P $PASSWORD -D $CLIENT_NAME
locale is "en_US.UTF-8"
locale charset is "UTF-8"
using default charset "UTF-8"
Setting $CLIENT_NAME as default database in login packet
Error 20017 (severity 9):
Unexpected EOF from the server
Error 20002 (severity 9):
Adaptive Server connection failed
Error 20002 (severity 9):
Adaptive Server connection failed
There was a problem connecting to the server

There is no routing issue to the host; I was able to see four packets replying from the SQL server to my Ubuntu LTS 20.04 machine. Perhaps significantly, three had zero-length payloads; the second of the four had a payload of 43 bytes. Hex dump of this packet wasn't revealing (presumably it was encrypted or binary in nature).

An Ubuntu LTS 18.04.3 server on the same network using the stable version of FreeTDS was able to connect without errors using the same credentials. Happy to provide whatever other details I can to resolve this issue.

Same result with freetds-1.1.33 and freetds-dev.1.1.62.

[freddy77]

One issue can be the encryption. Linux tends to increase the security levels faster than Windows. Sometimes so fast than when they try to find a common ground they cannot.

Which SQL server version are you using? Which Windows version?

You could try with something like

TDSVER=7.0 tsql -H $SERVER_IP -p 2001 -U $USERNAME -P $PASSWORD -D $CLIENT_NAME

(it uses a very old TDS protocol version which does not have encryption, I won't recommend for production! Just to try if it connects)

[kafran]

It is probably related to this issue: #299 (comment), probably related to newer version of openssl. Try the workaround found by @r313pp. I compiled it with GnuTLS and it also worked. @freddy77 do you know if there is any advise about using GnuTLS?

[jeffkirk1]

@freddy77: Overriding the TDS version to 7.0 does work around the problem. Thank you!
@kafran: I will investigate compiling with GnuTLS and report back.

[jeffkirk1]

The workaround by @r313pp might not work; the /etc/ssl/openssl.cnf file on Ubuntu 20.04 LTS doesn't define either MinProtocol or CipherString.

[jeffkirk1]

I was able to connect to the upstream server using tsql compiled with gnutls. To install GnuTLS, I compiled libgmp from source and ran the following command to install the other prerequisites:

sudo apt install nettle-dev libtasn1-6-dev libunistring-dev libunbound-dev libp11-kit-dev

This is to an Ubuntu 20.04 LTS headless server install, with the ubuntu-desktop tasksel package added after the fact.

FYI, on Ubuntu 20.04 LTS, fourteen of the "make check" unit tests fail without GnuTLS and thirteen with.

[kafran]

The workaround by @r313pp might not work; the /etc/ssl/openssl.cnf file on Ubuntu 20.04 LTS doesn't define either MinProtocol or CipherString.

I don't know about Ubuntu. I'm trying to compile into a Debian Buster Docker.

@freddy77: Overriding the TDS version to 7.0 does work around the problem. Thank you!

Apparently TDS 7.0 don't use encryption, that's why it works. I think this is not recommended for production.

[freddy77]

No, TDS 7.0 is surely not recommended. You could try setting encryption to off (http://www.freetds.org/userguide/freetdsconf.htm). Not that usually only the login part is encrypted, if you are in a safe LAN it could be sensible. Not sure if is possible,despite global system settings to force OpenSSL to use some not so insecure ciphers (recently Linux configurations are pretty strict about it).

Should I keep this issue open? I think it would be nice to have in the FAQ, which I think don't get updated since years.

[mckaygerhard]

i followed the usage of GnuTLS cos openssl are a mess !

Apparently TDS 7.0 don't use encryption, that's why it works. I think this is not recommended for production.

@kafran quite funny ... any M$ are not recommended in general! 😄

Should I keep this issue open? I think it would be nice to have in the FAQ, which I think don't get updated since years.

@freddy77 added to faq and close the issue.. as i pointed M$ products are not so easy to "complain", maybe in future when openssl become less complicated and does not cause a mess on every upgrade, may we have to merge issues with #299 and use GnuTLS that seems worked!

[rgyu]

We experience the similar issue. FreeTDS 7.4 connecting to SQL Server encounters the error: Adaptive Server connection failed. We thought it might be related to the MaxTokenSize setting on server side, but seems not.

We downgrade TDS to 7.0 and now can connect to SQL Server. Later, We identified that network security has a change. They add a security policy, and the network packet was dropped/altered by the policy. Once they remove the policy, FreeTDS connecting to SQL Server is OK.

So if you experience the similar issue, you can also ask network security team whether they have any change.

[mckaygerhard]

.. We identified that network security has a change.
They add a security policy, and the network packet was dropped/altered by the policy.
Once they remove the policy, FreeTDS connecting to SQL Server is OK.
So if you experience the similar issue, you can also ask network security team whether they have any change.

can you documented exactly what kind of change for freetds project ? please @yurongga !

[fziglio]

I think the issue here is that new Debian based distros has pretty high standards about TLS. Mostly the minimum required by the system are higher than what Windows system (and so the server) can accept.

TDS 7.0 did NOT support TLS so maybe this is the reason but be advised you are using a pretty old protocol which could lead to minor data corruption.

[rgyu]

we use pymssql in our project running on CentOS. Below is our code:

pymssql.connect(server=dns, port=port, database=dbname, user=uid, password=pwd,
charset="UTF-8",timeout=timeout, login_timeout=connect_timeout)

which runs fine. Suddently, it continues to throws error: "Adaptive Server connection failed". We have another working client that can connect to sql server successfully. We compared the TDS sending packet for both failed and successful clients. and the TDS sending packet are exactly the same. at that time, we have no idea, and found this discussion thread. our workaround is to specify TDS version to 7.0 like below:

pymssql.connect(server=dns, port=port, database=dbname, user=uid, password=pwd,
charset="UTF-8",timeout=timeout, login_timeout=connect_timeout,
tds_version="7.0")

the final solution is to ask network security team to remove the security policy. looks like AC policy related, but I don't know the security policy detail.

.. We identified that network security has a change.
They add a security policy, and the network packet was dropped/altered by the policy.
Once they remove the policy, FreeTDS connecting to SQL Server is OK.
So if you experience the similar issue, you can also ask network security team whether they have any change.

can you documented exactly what kind of change for freetds project ? please @yurongga !