Unexpected EOF when connecting to server from Ubuntu LTS 20.04 #336
Comments
|
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) |
|
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? |
|
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 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. |
I don't know about Ubuntu. I'm trying to compile into a Debian Buster Docker.
Apparently TDS 7.0 don't use encryption, that's why it works. I think this is not recommended for production. |
|
No, TDS 7.0 is surely not recommended. You could try setting 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. |
|
i followed the usage of GnuTLS cos openssl are a mess !
@kafran quite funny ... any M$ are not recommended in general! 😄
@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! |
|
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. |
can you documented exactly what kind of change for freetds project ? please @yurongga ! |
|
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. |
|
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, 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, 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.
|
|
FreeTSD 1.3.10, TDS 7.4 with GnuTLS worked well. Specifying 7.0 at the configure step won't work as it's insecure. It's also possible to set |
|
I'm having a similar issue (only recently) on Mac OS. No matter how far I turn down the TDS version in freetds.conf, freetds sends a "prelogin" packet to the server on initial connection, which produces the premature EOF. I have to set "encryption = off" to stop the error. This is painful, because there's no way to turn off encryption without modifying freetds.conf, which doesn't play nicely with my application deployment (I can change TDS version with an environment variable, which suits me nicely). freetds: 1.3.18_1 (via homebrew) I'm more than happy to provide a more detailed bug report on request. Having just identified the bug and workaround, I'm scrambling to test and push out a new build for my app. |
|
Microsoft introduced encryption and prelogin with SQL Server 2000, you should configure and use FreeTDS with encryption, not trying to use a protocol version more than 20 years old. What says |
|
I'm offering a patch, hoping for some feedback on what the proper fix is (or, of course, on how I'm misstating the problem). Thanks for the advice, @freddy77. I'm not seeking to use an older protocol version--I was only trying that to see if it would circumvent my pre-login issue.1 I'm connecting to SQL Server 2014, which (for my current deployment, at least) returns a well-formed pre-login response2. I'm not yet sure which side is closing the connection. I am saying that the freetds bug is any or all of:
It's certainly the case that users should be upgrading insecure deployments. However, in my current example, I'm using a reasonably modern, encryption-capable database, and my client is failing with no useful diagnostics only after a freetds upgrade. None of the relevant software is giving me the information I require to know what's wrong or how to fix it. 1 I've since discovered that, if I back off all the way to TDS 7.0 (as per #336 (comment), thanks @jeffkirk1), the client will skip the pre-login, which is a better workaround for me than deploying a custom freetds.conf. This issue only triggers with a diagnostic client, not with my customer-facing app (which uses jtds, not freetds). 2 Pre-login response packet: Decoded: |
I would bet the server. If you use a network capture software you can see clearly which end post the first packet with FIN flag.
Tried with the data you sent, no, no problem decoding
I would bet server is silently closing the connection due to failure in TLS handshaking. Not sending detailed errors is common with many server to avoid giving informations to attackers.
What's the point to connect again? If the error is due to configuration you need to update the configuration.
Which version of Windows (server) are you using?
it's recommended to leave to auto, unless you are using Sybase.
nice!
Try something like TDSDUMP=stderr tsql -H server -p 1433Getting something like note that crypt flag is detected and program start initializing TLS (I was trying to reproduce parsing your prelogin). |
|
Confirmed that the server is closing the connection. Server OS: Windows Server 2008 R2 Standard Contents of /tmp/freetds.log: So to update, I am asserting that: freetds is not providing informative diagnostics on the disconnection. For example, logging that the server closed the connection after returning a well-formed pre-login response would tell me that I probably shouldn't start my investigation with a call to network ops. freetds is not (optionally) attempting to reconnect without the pre-login phase. By this, I mean that it would be nice if there were a (perhaps configurable) way to get freetds to try again without sending the pre-login message. I understand that you're not enthused by this, @freddy77, but if I know what I'm doing and I've been living without connection encryption all this time (in my case, in an environment in which encrypted connections would provide no additional security), I don't see it as a net positive that I I have no encryption and I don't get to use bigint, varchar(max), varbinary(max), or MARS. |
Microsoft ended support for such system 3 years ago.
The log was enough to tell you that. I don't see much a mistake in the general "error connecting" and the more detail are returned in the logs. On the log is also clear that the prelogin phase was successful and the client sent the initial TLS but the server closed the connection. This is probably due to the server not accepting the two restricted (because more secure) client settings. This confirm that you need to relax your client security configuration in order to connect.
No, that is insecure. Recently Microsoft clients also check the server certificate so in some way is even more strict. Note that you can still attempt to use a former protocol but this is intentionally not make easy so you need to use I understand your environment is closed so this prevents attacks that need encryption however I still recommend to lower the client security setting and use proper TDS protocol. See for instance https://stackoverflow.com/questions/57265913/error-tcp-provider-error-code-0x2746-during-the-sql-setup-in-linux-through-te (as you can see same issue but with Microsoft client). |
|
@freddy77 you closed but you can paste commit referes so can helps mantainers work of distros? |
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.
The text was updated successfully, but these errors were encountered: