http://bugs.winehq.org/show_bug.cgi?id=19144
Summary: QueryContextAttributesW returns wrong return value Product: Wine Version: 1.1.24 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: secur32 AssignedTo: wine-bugs@winehq.org ReportedBy: andras@csevego.net
If a .net application wants to connect to an mssql server, it will fail because of wine's secur32.dll (schan) return value. It should return 0 (SEC_E_OK), but it returns -2146893048. I got a successful connection with native secur32.
I have done some further investigation: If I manually return 1 at scannel.c:872 (return SEC_E_OK;), I got error 1 in error dialog. But if I pass 0, I got -2146893048.
MSSQL Management Studio's error in detail:
TITLE: Connect to Server ------------------------------
Cannot connect to <ip addr>.
------------------------------ ADDITIONAL INFORMATION:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - SSL Provider: ) (Microsoft SQL Server, Error: -2146893048)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQ...
------------------------------ BUTTONS:
OK ------------------------------
I tested with a private .net application, and MSSQL Management Studio 2005 Express. I have .net Framework 3.5 installed under wine. (with Louis Lenders' lsa and wbemprox patch)
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2009-07-01 10:46:53 --- A +secur32 trace might help.
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #2 from Andras Kovacs andras@csevego.net 2009-07-01 10:54:42 --- Created an attachment (id=22132) --> (http://bugs.winehq.org/attachment.cgi?id=22132) secur32 log
http://bugs.winehq.org/show_bug.cgi?id=19144
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
--- Comment #3 from Juan Lang juan_lang@yahoo.com 2009-08-05 15:22:15 --- -2146893048 is 0x80090308, SEC_E_INVALID_TOKEN. I'm not sure where that's coming from, as schannel.c never returns it.
Could you patch secur32 as you propose, and attach a +secur32 log with that change? That'll at least help us identify if returning 1 is what the application is expecting.
Or, the best thing you could do is to write some tests for QueryContextAttributes. MSDN says QueryContextAttributes returns 0 on success, nonzero on failure, whereas some sample code on MSDN checks the return value with the FAILED macro. The FAILED macro only applies to HRESULTs, and any non-negative value "passes" with an HRESULT. A test would show what native secur32/schannel returns for SECPKG_ATTR_STREAM_SIZES, as well as what values it puts into the returned SecPkgContext_StreamSizes structure.
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2009-08-05 15:35:36 --- (In reply to comment #0)
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - SSL Provider: ) (Microsoft SQL Server, Error: -2146893048)
Notice that the first error is 0, which is what schannel returns. The second error, the "Microsoft SQL Server" error, is SEC_E_INVALID_TOKEN. I suspect that by changing schannel.c to return 1, you're affecting the first error, but that's not really where the problem is. Googling more leads me to suspect that returning 0 is what's expected, as several snippets of sample code check against SEC_E_OK rather than using FAILED. Here are a few examples:
http://msdn.microsoft.com/en-us/library/aa375205(VS.85).aspx http://exodus.googlecode.com/svn/trunk/exodus/idSSLSchannel.pas http://www.eggheadcafe.com/forumarchives/platformsdksecurity/Jul2005/post233...
Perhaps a +secur32,+relay trace might give us some idea where the SEC_E_INVALID_TOKEN is coming from?
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #5 from Henri Verbeet hverbeet@gmail.com 2009-08-05 16:17:04 --- Perhaps this is completely unrelated, but note that we don't yet do a whole lot with the requested cipher algorithms etc. in AcquireCredentialsHandle(). The "Using hardcoded "NORMAL" priority" FIXME is related to that.
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #6 from Andras Kovacs andras@csevego.net 2009-08-05 16:50:14 --- Look at this sniplet:
trace:secur32:schan_QueryContextAttributesW context_handle 0x1bc010, attribute 0x4, buffer 0x35cdb48 trace:secur32:schan_QueryContextAttributesW Using 16 mac bytes, block size 1 (...) 001d:Call KERNEL32.TlsSetValue(0000000c,80090308) ret=65001800 001d:Ret KERNEL32.TlsSetValue() retval=00000001 ret=65001800 (...)
I think it checks something, what QueryContextAttributesW returns, and set into a TLS. (80090308 is SEC_E_INVALID_TOKEN)
Debug log (its huge, because it's a .net app): http://mgmt.sth.sze.hu/~andras/wine/hatar/relay_secur32.log.bz2
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #7 from Juan Lang juan_lang@yahoo.com 2009-08-05 17:13:32 --- (In reply to comment #6)
Look at this sniplet:
trace:secur32:schan_QueryContextAttributesW context_handle 0x1bc010, attribute 0x4, buffer 0x35cdb48 trace:secur32:schan_QueryContextAttributesW Using 16 mac bytes, block size 1 (...) 001d:Call KERNEL32.TlsSetValue(0000000c,80090308) ret=65001800 001d:Ret KERNEL32.TlsSetValue() retval=00000001 ret=65001800 (...)
I think it checks something, what QueryContextAttributesW returns, and set into a TLS. (80090308 is SEC_E_INVALID_TOKEN)
Thanks for uploading the log.
I agree that it's likely to have something to do with what QueryContextAttributesW returns, but I think it's more likely that its in the value in the returned buffer, and not the return value. Henri may have a point that we're ignoring something we shouldn't in creating the connection. I'll attach a patch that traces the input a bit more that may give more insight.
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #8 from Juan Lang juan_lang@yahoo.com 2009-08-05 17:14:48 --- Created an attachment (id=22840) --> (http://bugs.winehq.org/attachment.cgi?id=22840) Patch: Trace values of SCHANNEL_CRED structure
Could you upload a +secur32 log with this patch applied?
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #9 from Andras Kovacs andras@csevego.net 2009-08-05 17:48:57 --- Created an attachment (id=22842) --> (http://bugs.winehq.org/attachment.cgi?id=22842) +secur32 with patch
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #10 from Juan Lang juan_lang@yahoo.com 2009-08-05 18:03:22 --- Okay, from your log: trace:secur32:schan_CheckCreds grbitEnabledProtocols = 000000f0
That's SP_PROT_TLS1_CLIENT | SP_PROT_TLS1_SERVER | SP_PROT_SSL3_CLIENT | SP_PROT_SSL3_SERVER. I'm not sure whether gnutls supports SSL2 or not, but the log also shows:
trace:secur32:schan_gnutls_log <3> HSK[7c8946a0]: Server's version: 3.1
That's TLS1, so I think that's fine.
Next up, flags: trace:secur32:schan_CheckCreds dwFlags = 00000034
That's SCH_CRED_AUTO_CRED_VALIDATION | SCH_CRED_NO_DEFAULT_CREDS | SCH_CRED_NO_SERVERNAME_CHECK. SCH_CRED_NO_DEFAULT_CREDS is fine, since we don't have automatic client credentials in Wine. SCH_CRED_AUTO_CRED_VALIDATION is also fine, that's all we ever do at the moment. SCH_CRED_NO_SERVERNAME_CHECK is also fine, because we never check the server name against the supplied certificate, even when we should.
So I don't think there should be any mismatch between what the application requested and the connection we actually made.
Some test cases for what native secur32 returns for the QueryContextAttributesW would sure be helpful. Even if they're not proper regression tests, just a little test application that connects to your server and prints out what the values of the returned SecPkgContext_StreamSizes are, to see if they're different between native and Wine, would help.
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #11 from Henri Verbeet hverbeet@gmail.com 2009-08-06 03:05:38 --- (In reply to comment #6)
(...) 001d:Call KERNEL32.TlsSetValue(0000000c,80090308) ret=65001800 001d:Ret KERNEL32.TlsSetValue() retval=00000001 ret=65001800 (...)
I think it checks something, what QueryContextAttributesW returns, and set into a TLS. (80090308 is SEC_E_INVALID_TOKEN)
The TlsSetValue() call is most likely just SetLastError().
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #12 from Andras Kovacs andras@csevego.net 2010-08-02 14:59:51 --- The first problem: We set 16 + 256 in cbTrailer elem, windows sets simply 16. If I change to 16 (mac_size), it goes further. The next error is: A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - TCP Provider: ) (Microsoft SQL Server, Error: 10054)
AFAIK 10054 is connection reset.
Finally windows's values of stream sizes: header=5 trailer=16 maximummsg=16384 buffers=4 blocksize=1
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #13 from Andras Kovacs andras@csevego.net 2010-08-02 16:00:33 --- I found a little example about using scannel (http://www.coastrd.com/c-schannel-smtp). I modified a little bit to display values we need (stream sizes). It connect securely to gmail smtp server and communicates with it. On win 7 it completes successfully, but on wine it freezes (it doesn't depends on previous comment about changing trailer's value).
Application (source project, compiled version with msvc express 2008) can be downloaded with logs from here:
http://mgmt.sth.sze.hu/~andras/wine/scanneltest.tar.gz
http://bugs.winehq.org/show_bug.cgi?id=19144
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, testcase URL| |http://mgmt.sth.sze.hu/~and | |ras/wine/scanneltest.tar.gz
http://bugs.winehq.org/show_bug.cgi?id=19144
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|download | CC| |00cpxxx@gmail.com
--- Comment #14 from Bruno Jesus 00cpxxx@gmail.com 2013-02-18 20:03:22 CST --- Is this still an issue in wine 1.5.24?
The download link is now 404, is it possible to attach the test?
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #15 from Andras Kovacs andras@sth.sze.hu 2013-02-19 00:33:37 CST --- I can not test it right now, the original problem has gone. It is possible nowadays to connect to mssql with management studio.
If you can test it, here is the file: http://home.sth.sze.hu/~andras/wine/scanneltest.tar.gz
http://bugs.winehq.org/show_bug.cgi?id=19144
Andras Kovacs andras@sth.sze.hu changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #16 from Andras Kovacs andras@sth.sze.hu 2013-02-19 02:43:49 CST --- I tested it. It works. I'm closing.
http://bugs.winehq.org/show_bug.cgi?id=19144
--- Comment #17 from Alexandre Julliard julliard@winehq.org 2013-03-01 14:50:30 CST --- Closing bugs fixed in 1.5.25.
http://bugs.winehq.org/show_bug.cgi?id=19144
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #18 from Alexandre Julliard julliard@winehq.org 2013-03-01 15:09:55 CST --- Really closing bugs fixed in 1.5.25.
http://bugs.winehq.org/show_bug.cgi?id=19144
Muhammad Zafar Iqbal mohammadzafariqbal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mohammadzafariqbal@gmail.co | |m
-
wine-bugs＠winehq.org