Skip to Content.
Sympa Menu

freetds - Re: [freetds] using freetds 0.64 with MS SQL 2005 with ssl, encryption forced on at server results in query timeout error

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] using freetds 0.64 with MS SQL 2005 with ssl, encryption forced on at server results in query timeout error
  • Date: Tue, 5 Jun 2007 11:34:18 -0400

Bob Hetzel wrote:
> login.c:973:quietly sending TDS 7.0 login packet
> token.c:309:tds_process_login_tokens()
> net.c:941:in tds_pull_func
> util.c:334:tdserror(0x80810a8, 0x80844b8, 20004, 104)
> util.c:370:tdserror: client library returned TDS_INT_CANCEL(2)
> util.c:391:tdserror: returning TDS_INT_CANCEL(2)
> util.c:162:Changed query state from IDLE to DEAD
> token.c:313:looking for login token, got 0()

I don't know the answer. I looked into it a little bit, so I know roughly
what's going on. If I can find time tonight, I may try to expand the
network-level logging to make the TDSDUMP log more useful for something
like this. But that won't fix anything; it will just make tracing a
little easier.

After sending the login packet, the client attempts to read from the
server. It gets a network error (not a timeout), 20004, above, indicating
the server closed the connection. That's not what should happen; it
indicates a TDS protocol violation. If you obey the protocol but have a
bad login, the server will return an error message packet before
terminating the session.

When the error occurs, the stack looks like this:

tds7_send_login() sent the login packet
tds_process_login_tokens()
tds_get_byte()
tds_read_packet()
goodread()
SSL_read()?
tds_pull_func()
tds_goodread()
read(2) or recv(2) => error
tdserror() passing 20004, TDSEREAD
[close socket, return error status]

I don't know anything about the SSL code or how it works. What seems to
be happening is the server is unhappy with the login packet it receives,
and closes the connection immediately. The evidence: the next attempt by
the client to read a single byte -- the packet type marker -- fails.

One interesting feature of your log is that libtds calls tdserror() twice.
tds_goodread() calls it with TDSEREAD, and, way up the stack,
tds_connect() calls it with TDSEFCON ("Adaptive Server connection
failed"). Maybe that's OK, or maybe we should have a "I told him already"
flag of some kind to prevent a proliferation of errors.

HTH.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page