[Bug 21106] New: RPC clients that connect via ncacn_ip_tcp to a Windows RPC server are broken
http://bugs.winehq.org/show_bug.cgi?id=21106
Summary: RPC clients that connect via ncacn_ip_tcp to a Windows RPC server are broken Product: Wine Version: 1.1.35 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: rpc AssignedTo: wine-bugs@winehq.org ReportedBy: winesku@googlemail.com CC: robertshearman@gmail.com
Created an attachment (id=25343) --> (http://bugs.winehq.org/attachment.cgi?id=25343) Call Stack in 1.1.35 when things go awry
With version 1.1.35, all my RPC clients that work over ncacn_ip_tcp to connect to a windows server don't work anymore. Things still worked without any problems in version 1.1.34. The problem is, that now with version 1.1.35, every RPC fails because NdrClientCall2 returns ERROR_NOT_ENOUGH_SERVER_MEMORY (1130, "Not enough server storage is available to process this command"). I have debugged this and things start to fail when NdrClientCall2 is in the PROXY_GETBUFFER phase. There it calls into the following call stack
rpcrt4_conn_tcp_read at rpc_transport.c 1452 rpcrt4_conn_read at rpc_binding.h 77 RPCRT4_default_receive_fragment at rpc_message.c 1297 RPCRT4_receive_fragment at rpc_message.c 1363 RPCRT4_ReceiveWithAuth at rpc_message.c 1396 RPCRT4_Receive at rpc_message.c 1553 I_RpcReceive at rpc_message.c 1851 I_RpcSendReceive at rpc_message.c 1911 NdrSendReceive at ndr_clientserver.c 214 NdrClientCall2 at ndr_stubless.c 747
Please also see my attachments to this issue with screenshots of the debugger when things go wrong in 1.1.35 and the same situation in 1.1.34 where things worked. I will also attach a couple binaries to easily repro the problem.
http://bugs.winehq.org/show_bug.cgi?id=21106
--- Comment #1 from Stefan Kuhr winesku@googlemail.com 2009-12-21 11:43:00 --- Created an attachment (id=25344) --> (http://bugs.winehq.org/attachment.cgi?id=25344) Call Stack in 1.1.34 in the same situation when things work
http://bugs.winehq.org/show_bug.cgi?id=21106
--- Comment #2 from Stefan Kuhr winesku@googlemail.com 2009-12-21 11:52:09 --- Created an attachment (id=25346) --> (http://bugs.winehq.org/attachment.cgi?id=25346) Simple client and server that show this bug, when running the server on a windows box and the client on Wine
Run the server on a windows box in a comand shell. It has a single commandline parameter that is interpreted as the port on which it listens for incoming RPCs. Run it e.g. like this:
rpcsrv.exe 4711
and it will listen on port 4711 for incoming RPCs.
Now start the client on a Wine box without any command line parameters. Chose TCP/IP as the protocol sequence and the port number you used for the server in the previous step (4711 in my example). Supply the IP address or the DNS name of the windows box, where the server is running as the computer name. Then enter credentials of a valid user on the windows box as user name, domain name and password. If your windows and Wine box is not running in a windows domain, you can leave the domain name entry empty, IIRC, as an alternative supply a dot or the windows box' computer name as the domain name. Now type something in the field "text to submit" and press the "Call RPC" button. In version 1.1.35 an error message box with "1130 Not enough server storage is available to process this command.") will be shown, in 1.1.34, the RPC will be executed on the server side an will show a dialog box on the server side.
http://bugs.winehq.org/show_bug.cgi?id=21106
--- Comment #3 from Stefan Kuhr winesku@googlemail.com 2009-12-21 11:53:12 --- Created an attachment (id=25347) --> (http://bugs.winehq.org/attachment.cgi?id=25347) The Visual Studio project for the sample RPC client/server package in case someone wants to build it
http://bugs.winehq.org/show_bug.cgi?id=21106
--- Comment #4 from Stefan Kuhr winesku@googlemail.com 2009-12-21 11:55:59 --- Please let me know if I can try out things for you, apply patches to my local GIT tree in order to see if things work again with that. I'll be happy to help get the RPC client functionality work again as it did until and including version 1.1.34.
http://bugs.winehq.org/show_bug.cgi?id=21106
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression, | |testcase
--- Comment #5 from Austin English austinenglish@gmail.com 2009-12-21 12:19:08 --- If this worked in 1.1.34, please run a regression test: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=21106
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|major |normal
http://bugs.winehq.org/show_bug.cgi?id=21106
--- Comment #6 from Stefan Kuhr winesku@googlemail.com 2009-12-22 06:25:58 --- Hello everyone,
I ran the regression tests with git bisect and this is the result:
e27e61db71e8f0279e3cbc09e32d8f85acde3159 is first bad commit commit e27e61db71e8f0279e3cbc09e32d8f85acde3159 Author: Rob Shearman robertshearman@gmail.com Date: Sun Dec 13 21:35:39 2009 +0000
rpcrt4: Add support for server-side authentication.
:040000 040000 cfb0134bdcd4694e566f42be4df2eb8c1a97b495 ad9faca181dc224c4902d99693e13ad0b79a3894 M dlls
http://bugs.winehq.org/show_bug.cgi?id=21106
--- Comment #7 from Stefan Kuhr winesku@googlemail.com 2010-01-18 08:06:57 --- I have meanwhile found out, which exact change in the changeset, that I determined via git bisect, had introduced this regression. It is the change in RPCRT4_BuildAuthHeader where
header->common.frag_len = 0x14;
had been replaced with
header->common.frag_len = sizeof(header->common);
sizeof(header->common) is 0x10 bytes and this is probably something that windows RPC servers do not like. So if I replace in my current local git repository sizeof(header->common) again with 0x14 in this assignment, everything works again as before. I dunno if the 12 bytes of extra allocation for HeapAlloc need to be reapplied again if things are reverted in this function, it didn't seem to be necessary in my case. Setting header->common.auth_len to zero is most probably not necessary as well since it is taken care of with the HeapAlloc statement and initialization to zero. So everything that needs to be done is setting header->common.frag_len to 0x14, at least this is, what my tests tell me.
http://bugs.winehq.org/show_bug.cgi?id=21106
Rob Shearman robertshearman@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #8 from Rob Shearman robertshearman@gmail.com 2010-01-25 16:09:40 --- Fixed by this commit: http://source.winehq.org/git/wine.git/?a=commitdiff;h=c66972dfbabf5b16705716...
http://bugs.winehq.org/show_bug.cgi?id=21106
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2010-02-05 11:39:08 --- Closing bugs fixed in 1.1.38.
-
wine-bugs＠winehq.org