http://bugs.winehq.org/show_bug.cgi?id=22064
Summary: The Settlers 7 Demo fails to start Product: Wine Version: 1.1.40 Platform: x86 URL: http://www.pfanni.de/de/die-siedler-7-exklusiv-demo.as p OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: c_korn@gmx.de
Created an attachment (id=26879) --> (http://bugs.winehq.org/attachment.cgi?id=26879) wine-1.1.40 output
The game does not start because of the great copyprotection Ubisoft uses. It requires an Internet connection during gameplay and tries to somehow setup a proxy for this. And this fails.
There is only a message window telling: failed to start proxy instance
http://bugs.winehq.org/show_bug.cgi?id=22064
Christoph Korn c_korn@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #1 from Jeff Zaroyko jeffz@jeffz.name 2010-03-19 00:34:57 --- Same debug message from the game about not being able to start the proxy interface in bug 22036, another ubisoft title. Maybe that one should be marked a duplicate of this, since there is a demo for this one.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #2 from Juan Lang juan_lang@yahoo.com 2010-03-19 11:24:31 ---
From your log:
! DNS Server may be unavailable or inaccessible.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ! Network problems where detected - you may experience problems connecting to the Ubisoft servers. !
and later:
Adapter DNS: None
I wonder whether Ubisoft expects the adapter DNS returned by GetPerAdapterInfo not to be empty. This could just be a red herring, of course. A +relay log might help.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #3 from Christoph Korn c_korn@gmx.de 2010-03-20 11:31:43 --- Created an attachment (id=26914) --> (http://bugs.winehq.org/attachment.cgi?id=26914) +relay log of wine-1.1.41
This relay log does not contain the GetPerAdapterInfo function you mentioned.
This is all adapter related: $ grep -i Adapter log_relay 002b:Call KERNEL32.GetProcAddress(7e740000,00470b90 "GetAdaptersAddresses") ret=0043cc2d 002b:Call iphlpapi.GetAdaptersAddresses(00000002,00000000,00000000,00000000,00328270) ret=0043cc73 002b:Call ntdll.RtlFreeHeap(00110000,00000000,001490f0) 0021:Ret ntd002b:Ret ntdll.RtlFreeHeap() retval=00000001 ret=70021:Cal002b:Ret iphlpapi.GetAdaptersAddresses() retv0021:Ret KERNEL32.TlsGetValue() retval=7b821e9c ret=78543596 002b:Call iphlpapi.GetAdaptersAddresses(00000002,000000021:Ret KERNEL32.FlsGetValue() retval=01804138 ret=785435af Adapter name: lo Adapter index: 2 (0x2) Adapter id: eth0 Adapter Desc: eth0 Adapter medium: unknown Adapter Flags: 0 Adapter MTU: 16436 Adapter type: MIB_IF_TYPE_ETHERNET Adapter IfType: IF_TYPE_SOFTWARE_LOOPBACK Adapter Status:002b:Ret KERNEL32.WriteFile() retval=00000001 ret=00421fab Adapter Addr: 0-1c-23-96-86-1f Adapter DNS: None Adapter name: lo Adapter index: 3 (0x3) Adapter id: wlan0 Adapter Desc: wlan0 Adapter medium: unknown Adapter Flags: 0 Adapter MTU: 16436 Adapter type: MIB_IF_TYPE_ETHERNET Adapter IfType: IF_TYPE_SOFTWARE_LOOPBACK Adapter Status: IfOperStatusUp Adapter Addr: 0-13-e8-82-8c-81 Adapter DNS: None
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #4 from Juan Lang juan_lang@yahoo.com 2010-03-20 13:20:23 --- (In reply to comment #3)
This relay log does not contain the GetPerAdapterInfo function you mentioned.
(snip)
002b:Call iphlpapi.GetAdaptersAddresses(00000002,00000000,00000000,00000000,00328270) ret=0043cc73
Okay, that call also gets per-adapter DNS info. Wine doesn't have such a concept, because Unix doesn't really either. The concept is actually kind of braindead: how do you know which adapter you want to use, until you know which address you're trying to reach? Anyway, modifying GetAdaptersAddresses to include the DNS servers might be worth a try.
http://bugs.winehq.org/show_bug.cgi?id=22064
Alexandre Daoud alex.daoud@mac.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alex.daoud@mac.com
--- Comment #5 from Alexandre Daoud alex.daoud@mac.com 2010-03-21 08:57:04 --- I found that by using the Winex-7 prefix from Cedega (I use PlayOnLinux so it was easy to change the wine version), this problem does not occur, however it then claims that there are missing calls (winhttp.dll.WinHttpCreateUrl and winhttp.dll.WinHttpGetDefaultProxyConfiguration). These missing calls, I believe were implemented in 1.1.40 (according to the Assassin's Creed II bug report). If there was some way to use the iphlpapi.dll.so (this is where I believe the DNS problem comes from, cedega claims to have improved DNS support in this file from versions 5 and up) from cedega and merge it with the one from 1.1.40, it should work. What I don't understand is that why haven't Transgaming contributed these improvements to the Wine project. They are happily using files from the open-source community, the least they could do is contribute their improvements.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #6 from Austin English austinenglish@gmail.com 2010-03-21 12:05:15 --- (In reply to comment #5)
I found that by using the Winex-7 prefix from Cedega (I use PlayOnLinux so it was easy to change the wine version), this problem does not occur, however it then claims that there are missing calls (winhttp.dll.WinHttpCreateUrl and winhttp.dll.WinHttpGetDefaultProxyConfiguration). These missing calls, I believe were implemented in 1.1.40 (according to the Assassin's Creed II bug report). If there was some way to use the iphlpapi.dll.so (this is where I believe the DNS problem comes from, cedega claims to have improved DNS support in this file from versions 5 and up) from cedega and merge it with the one from 1.1.40, it should work.
Their source for it is here: http://www.cedega.com/development/git/gitweb.cgi?p=winex_lgpl.git/.git;a=tre...
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #7 from Alexandre Daoud alex.daoud@mac.com 2010-03-21 12:08:50 --- (In reply to comment #6)
(In reply to comment #5)
I found that by using the Winex-7 prefix from Cedega (I use PlayOnLinux so it was easy to change the wine version), this problem does not occur, however it then claims that there are missing calls (winhttp.dll.WinHttpCreateUrl and winhttp.dll.WinHttpGetDefaultProxyConfiguration). These missing calls, I believe were implemented in 1.1.40 (according to the Assassin's Creed II bug report). If there was some way to use the iphlpapi.dll.so (this is where I believe the DNS problem comes from, cedega claims to have improved DNS support in this file from versions 5 and up) from cedega and merge it with the one from 1.1.40, it should work.
Their source for it is here: http://www.cedega.com/development/git/gitweb.cgi?p=winex_lgpl.git/.git;a=tre...
Yeah, I found the source code and I integrate the two, but I failed miserably :P I'll have to wait until someone more experienced than me comes up with a patch...
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #8 from Juan Lang juan_lang@yahoo.com 2010-03-22 12:53:34 --- (In reply to comment #6)
Their source for it is here: http://www.cedega.com/development/git/gitweb.cgi?p=winex_lgpl.git/.git;a=tre...
This doesn't look very up to date to me. It's behind the winehq version, at any rate.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #9 from Juan Lang juan_lang@yahoo.com 2010-03-24 11:10:46 --- Created an attachment (id=27014) --> (http://bugs.winehq.org/attachment.cgi?id=27014) Patch: Set DNS servers in GetAdaptersAddresses
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=22064
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #10 from Christoph Korn c_korn@gmx.de 2010-03-25 16:44:09 --- This patch makes no difference. (I added FIXME("get_dns_server_addresses\n"); to the function to ensure it is called really)
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #11 from Juan Lang juan_lang@yahoo.com 2010-03-25 16:46:34 --- Thanks. What is the output with the patch applied? How about any differences in a +relay log?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #12 from Christoph Korn c_korn@gmx.de 2010-03-25 17:36:25 --- Created an attachment (id=27043) --> (http://bugs.winehq.org/attachment.cgi?id=27043) wine-1.1.41 output with patch attached
This is the normal wine output with your patch attached.
http://bugs.winehq.org/show_bug.cgi?id=22064
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #27043|application/octet-stream |text/plain mime type| |
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2010-03-25 17:47:15 --- Thanks. Oddness in the log persists. For example,
Adapter name: lo Adapter index: 2 (0x2) Adapter id: eth0
Why does it think the adapter name lo, I wonder? When I run a little test program to print out the adapter names and DNS servers, I certainly don't see lo assigned to every interface. And what's the meaning of the "Adapter id"?
Adapter DNS: None
And why is this still true?
Another possible culprit in your log: fixme:winsock:WSAEnumNameSpaceProvidersW (0x3282b0 0x3292d0) Stub!
I'm just grasping at straws, really.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #14 from Christoph Korn c_korn@gmx.de 2010-03-25 17:47:48 --- Created an attachment (id=27044) --> (http://bugs.winehq.org/attachment.cgi?id=27044) wine-1.1.41 +iphlpapi (with patch attached)
http://bugs.winehq.org/show_bug.cgi?id=22064
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #15 from Juan Lang juan_lang@yahoo.com 2010-03-25 17:57:44 --- *** Bug 22036 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #16 from Berillions berillions@gmail.com 2010-03-26 04:56:20 --- Hello,
For this error message : err:ntlm:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. err:ntlm:SECUR32_initNTLMSP Usually, you can find it in the winbind package of your distribution. err:ntlm:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. err:ntlm:SECUR32_initNTLMSP Usually, you can find it in the winbind package of your distribution.
You must to install winbind in your distribution.
****
It's very strange because "Silent Hunter 5", an Ubisoft's game use the same DRM system that "Assassin's Creed 2" and "The Settlers 7". In AppDB : http://appdb.winehq.org/objectManager.php?sClass=version&iId=19549 a player can playt correctly at this game so i can connect at Ubisoft's server.
http://bugs.winehq.org/show_bug.cgi?id=22064
William Pettersson william.pettersson@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |william.pettersson@gmail.co | |m
http://bugs.winehq.org/show_bug.cgi?id=22064
Chris hanashiaite@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #17 from Chris hanashiaite@gmail.com 2010-03-29 16:35:16 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=22064
Paweł Szymański out.of.logins.error@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |out.of.logins.error@gmail.c | |om
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #18 from Wylda wylda@volny.cz 2010-06-13 01:43:50 --- Created an attachment (id=28792) --> (http://bugs.winehq.org/attachment.cgi?id=28792) console log from wine-1.2-rc3
I did the test with Assassin's Creed 2 and clean wine-1.2-rc3. Looks like, that now we are few steps further. It successfully communicates with Ubisoft servers, but gives own messages:
PatchDownloader2.cpp (611) : failed to decode buffer PatchPage.cpp (235) : Patch error. Corrupt file? Restarting and retrying.
But few lines above says "I have the latest version, no need to patch" ;-) So not sure if i'm in right bug report, when i get further.
--private keyword: =DK=
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #19 from Berillions berillions@gmail.com 2010-06-14 05:08:55 --- Hello Wylda,
Try to launch AssassinCreedIIGame.exe and you will donwload/install the patch. After, re-launch AssassinCreedII.exe and you will have an other error message.
For me, when i launch AssassinCreedII.exe, i have a pop-up window in Wine who told me that I haven't an Internet Connection. In the console, i block on "PatchDownloader2.cpp" because Wine can't get a file in the Ubisoft's Server.
Berillions
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #20 from Berillions berillions@gmail.com 2010-06-14 11:34:16 --- Created an attachment (id=28828) --> (http://bugs.winehq.org/attachment.cgi?id=28828) AC2 and Wine 1.2-rc3
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #21 from Berillions berillions@gmail.com 2010-06-14 11:38:40 --- Humph, i'm a noob to create an attachment. So, i link the screen where there is the wine pop-up : http://pix.toile-libre.org/?img=1276533380.png
Translation French -> English : An Internet connection is necessary to play at this game. Impossible to connect at Ubisoft's server. Check your Internet connection and re-try
http://bugs.winehq.org/show_bug.cgi?id=22064
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wylda@volny.cz
--- Comment #22 from Wylda wylda@volny.cz 2010-06-19 07:58:44 ---
Still present in wine-1.2-rc4.
Berillions, i tried now AssassinsCreedIIGame.exe and AssassinsCreedII.exe, but both give me same results: "failed to get http://static3.cdn.ubi.com/orbit/products/4/latest.txt, patching will not work, trying to start app anyway"
Anyway, looks like that 1.2 will be cut of new Ubisoft's games.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #23 from Berillions berillions@gmail.com 2010-06-21 10:45:59 --- (In reply to comment #22)
Anyway, looks like that 1.2 will be cut of new Ubisoft's games.
So, goodby Linux end welcome Windows to play correctly in future Ubisoft's games
http://bugs.winehq.org/show_bug.cgi?id=22064
Achim Schaefer achim_schaefer@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |achim_schaefer@gmx.de
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #24 from Mikko Rasa tdb@tdb.fi 2010-08-17 16:06:40 --- Created an attachment (id=30205) --> (http://bugs.winehq.org/attachment.cgi?id=30205) Make cryptographic message verification work
This patch gets rid of the "corrupted file" error and allows the game launcher to patch itself successfully.
Those "can't download file" errors go away with setting WINEDEBUG=+winhttp. Apparently there's some timing issues and the debug messages make it slow enough to work.
However, the launcher still isn't happy. It's getting the list of authentication server, but claims it can't communicate with them. It opens a connection to port 13000 of one of the servers and there's some data going back and forth, but apparently it isn't the correct data. After trying for a minute or so the launcher gives up and displays an error dialog.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #25 from Juan Lang juan_lang@yahoo.com 2010-08-17 18:29:37 --- (In reply to comment #24)
Created an attachment (id=30205)
--> (http://bugs.winehq.org/attachment.cgi?id=30205) [details]
Make cryptographic message verification work
This patch gets rid of the "corrupted file" error and allows the game launcher to patch itself successfully.
Interesting, but the patch is incorrect: it causes a test failure.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #26 from Juan Lang juan_lang@yahoo.com 2010-08-17 18:31:03 --- Could you attach a +crypt log with and without the patch applied?
http://bugs.winehq.org/show_bug.cgi?id=22064
Mikko Rasa tdb@tdb.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30205|0 |1 is obsolete| |
--- Comment #27 from Mikko Rasa tdb@tdb.fi 2010-08-18 14:54:20 --- Created an attachment (id=30213) --> (http://bugs.winehq.org/attachment.cgi?id=30213) Fixed crypt32 patch
Here's a corrected version of the patch which passes tests
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #28 from Mikko Rasa tdb@tdb.fi 2010-08-18 14:56:43 --- Created an attachment (id=30214) --> (http://bugs.winehq.org/attachment.cgi?id=30214) Log without the crypto patch
Here's the log without the above patch. The game first calls CryptMessageVerifySignature with a NULL pcbDecoded to find out the decoded message size, then allocates a buffer for it and calls again. However, since pcbDecoded is cleared in the beginning, the rest of the function will think the buffer is zero bytes long and doesn't have enough space to copy the message in.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #29 from Mikko Rasa tdb@tdb.fi 2010-08-18 14:57:27 --- Created an attachment (id=30215) --> (http://bugs.winehq.org/attachment.cgi?id=30215) Log with the crypto patch
Here's a log with the above patch applied. You'll notice that now the second CryptVerifyMessageSignature call succeeds as well.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #30 from Mikko Rasa tdb@tdb.fi 2010-08-19 09:53:55 --- Created an attachment (id=30225) --> (http://bugs.winehq.org/attachment.cgi?id=30225) Fix "unable to download file" errors
This patch makes WinHttpQueryHeaders work properly, allowing the game launcher to download files. The issue wasn't timing related after all, but apparently enabling the debug channel just happened to cause the lpdwBufferLength variable to contain zero and make the function return the error code the launcher was expecting.
http://bugs.winehq.org/show_bug.cgi?id=22064
Mikko Rasa tdb@tdb.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tdb@tdb.fi
http://bugs.winehq.org/show_bug.cgi?id=22064
mc winehq@ukeer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@ukeer.de
--- Comment #31 from mc winehq@ukeer.de 2010-08-19 14:57:14 --- (In reply to comment #30)
Created an attachment (id=30225)
--> (http://bugs.winehq.org/attachment.cgi?id=30225) [details]
Fix "unable to download file" errors
i did download the ppa ubuntu source version of winehq, apply the patch manually, and indeed it starts the launcher. Now it fails at:
2010-08-19 21:55:17 [ 54] [DEBUG ] PatchDownloader2.cpp (544) : trying to get http://static3.cdn.ubi.com/orbit/patches_launcher/0121/filelist_signed.txt 2010-08-19 21:55:17 [ 56] [DEBUG ] HttpProxyConfig.cpp (289) : Testing direct connection to static3.cdn.ubi.com 2010-08-19 21:55:17 [ 56] [DEBUG ] HttpProxyConfig.cpp (304) : Successfully resolved static3.cdn.ubi.com 2010-08-19 21:55:17 [ 56] [DEBUG ] HttpProxyConfig.cpp (316) : Successfully created direct connection to static3.cdn.ubi.com 2010-08-19 21:55:17 [ 54] [DEBUG ] PatchDownloader2.cpp (611) : failed to decode buffer 2010-08-19 21:55:17 [ 54] [DEBUG ] PatchPage.cpp (235) : Patch error. Corrupt file? Restarting and retrying. 2010-08-19 21:55:17 [ 21] [DEBUG ] main.cpp (1155) : stopping launcher
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #32 from Mikko Rasa tdb@tdb.fi 2010-08-19 15:41:58 --- See the crypt32 patch in comment 27, that should fix the corrupt file problem
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #33 from Juan Lang juan_lang@yahoo.com 2010-08-19 15:59:43 --- (In reply to comment #32)
See the crypt32 patch in comment 27, that should fix the corrupt file problem
That patch was committed: http://source.winehq.org/git/wine.git/?a=commit;h=a4435e3adc6f35b66ea9e724f4... Just use latest git and that'll fix the corrupt file problem too.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #34 from Juan Lang juan_lang@yahoo.com 2010-08-20 10:42:05 --- Alexandre committed a fix for WinHttpQueryHeaders: http://source.winehq.org/git/wine.git/?a=commit;h=93208196c8e3609f16b7d4d0a8... What's the status with today's git?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #35 from Wylda wylda@volny.cz 2010-08-20 10:52:55 --- (In reply to comment #34)
What's the status with today's git?
Hi, i'm waiting 2hours already for a release :) Is release day today? When it gets out, i will go ahead and start testing a bit including this one...
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #36 from Berillions berillions@gmail.com 2010-08-20 17:30:53 --- Created an attachment (id=30247) --> (http://bugs.winehq.org/attachment.cgi?id=30247) output file
Hello,
I tried Wine 1.3.1 with Assassin's Creed 2. So, now i can update the launcher and wine don't crash. But, the launcher runs constantly. (See screenshot = http://img829.imageshack.us/img829/7786/capturerl.png )
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #37 from Juan Lang juan_lang@yahoo.com 2010-08-20 17:32:58 --- Console output?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #38 from Berillions berillions@gmail.com 2010-08-20 17:39:02 --- (In reply to comment #37)
Console output?
Yes :)
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #39 from Juan Lang juan_lang@yahoo.com 2010-08-20 17:49:53 --- Whoops, missed that, sorry! Rats, nothing sticks out in the output. A +relay log might see what it's doing when the splash screen is up.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #40 from Wylda wylda@volny.cz 2010-08-20 18:50:07 ---
I got in case of Assassion Creed II:
fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority err:ntdll:RtlpWaitForCriticalSection section 0x33e5b8 "?" wait timed out in thread 0033, blocked by 003c, retrying (60 sec) fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
Then new window pop up, that internet connection is not available. But on firs run, it downloaded and applied new patches :-D
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #41 from Berillions berillions@gmail.com 2010-08-21 04:41:21 --- (In reply to comment #39)
Whoops, missed that, sorry! Rats, nothing sticks out in the output. A +relay log might see what it's doing when the splash screen is up.
How may I help you?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #42 from Juan Lang juan_lang@yahoo.com 2010-08-22 21:39:50 --- (In reply to comment #41)
How may I help you?
Capture a +relay log, then kill the app after a while once it's hung. Look for repetition at the end of the log: there's often some sequence of calls the app is making over and over again, where one is failing that it's expecting to succeed. Attach the repeated bit here.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #43 from Mikko Rasa tdb@tdb.fi 2010-08-23 10:01:12 --- Created an attachment (id=30328) --> (http://bugs.winehq.org/attachment.cgi?id=30328) WINEDEBUG=+winsock,+crypt,+seh,+tid,+timestamps,+relay
Getting a log wasn't easy as the launcher developed a tendency to segfault when run with +trace. After several tries I was lucky enough to get one complete iteration of whatever it tries to do. Attached is a trace with +winsock,+crypt,+seh,+tid,+timestamps,+relay. I am not quite sure if I got the cutoff point entirely right, as the timestamp patch I'm using doesn't seem to apply to +relay.
There are some OutputDebugStringA calls in that trace which don't seem to end up on the terminal. Below is a dump of the strings, extracted with a bit of sed magic:
mg\httpproxy\HttpProxyConfig.cpp (289): Testing direct connection to static3.cdn.ubi.com mg\httpproxy\HttpProxyConfig.cpp (304): Successfully resolved static3.cdn.ubi.com mg\httpproxy\HttpProxyConfig.cpp (316): Successfully created direct connection to static3.cdn.ubi.com:80 mg\orbitdll\ProxyConn.cpp (198): connecting to 95.211.115.4:13000 mg\httpproxy\HttpProxyConfig.cpp (304): Successfully resolved 95.211.115.4 mg\httpproxy\HttpProxyConfig.cpp (316): Successfully created direct connection to 95.211.115.4:13000 mg\httpproxy\HttpProxyConfig.cpp (361): No proxy needed, creating direct connection to 95.211.115.4 mg\orbitdll\ProxyConn.cpp (213): Failed while waiting for hello message, timedout = yes mg\orbitdll\ProxyConn.cpp (181): Trying to connect to satellite; i=2, primary=yes mg\client\SatelliteList.cpp (146): Fetching serverlist from http://static3.cdn.ubi.com/orbit/satellitelist/satellitelist.txt
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #44 from Juan Lang juan_lang@yahoo.com 2010-08-23 11:39:14 --- Okay, I had a look. I'm guessing that this will be a challenge to debug from logs. Here's the error message you pointed out before:
003c:Call KERNEL32.OutputDebugStringA(02c64250 "mg\orbitdll\ProxyConn.cpp (213): Failed while waiting for hello message, timedout = yes\n") ret=1004b68c
So, assuming that message is actually indicative of the problem, we should expect to see some sort of wait prior to this. I see lots of calls like:
002e:Ret ws2_32.WSAGetLastError() retval=00000102
0x102 is STATUS_TIMEOUT, aka WAIT_TIMEOUT. In the log there's also a: [13.365371] 002e:trace:seh:raise_exception code=c0000005 flags=0 addr=0x1001d67a ip=1001d67a tid=002e
c0000005 is a crash. Perhaps this is a red herring, but I wonder whether this crash is somewhere in a thread which should have been receiving data, which causes it never to receive it? I suspect someone willing to disassemble the app and debug the crash that way will get further with this than I.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #45 from Mikko Rasa tdb@tdb.fi 2010-08-23 17:47:03 --- More accurately, c0000005 is an invalid memory access, also known as segfault for *nix folks. The launcher generates a lot of those, but most of them are handled.
There's something weird going on though; if +relay is enabled, there's one such exception which isn't caught by the program and generates the "serious error" dialog, causing that thread to be terminated. I wonder if there's something wrong with the +relay code in wine and it tries to read a value through some invalid pointer and thus generates a segfault the program isn't expecting?
I thought I had managed to get a "good" log where the program successfully made one attempt at communicating with the server, but either I cut the wrong part of the log or the segfault happened on the first try and I just didn't notice it while jumping back and forth.
I will continue poking at this problem and wine code later this week. Any pointers for locations which to poke are greatly appreciated.
Oh, and before I forget - I have a full version of the game. From what I know, the demo uses the same launcher and DRM though, so my findings should be relevant to it as well.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #46 from mc winehq@ukeer.de 2010-08-23 18:48:32 --- (In reply to comment #45)
There's something weird going on though; if +relay is enabled, there's one such exception which isn't caught by the program and generates the "serious error" dialog, causing that thread to be terminated. I wonder if there's something
Ive just checked out master from git and built: wine-1.3.1-68-g70d8fce
I cannot reproduce any crashes anymore, i trashed my ~/.wine directory, and let steam re-instate S7 (not by re-installing the game, but by installing some dx, the UGL and some third component). Afterwards i started S7, it did fetch some Update (to UGL, not to S7, i'd believe) and then i see the red box for a very long time (which, to me, indicates some progress, since the last attempts canceled the red box pretty fast). I tried also some WINEDEBUG, but had trouble finding something; i also disabled +relay for now, since only logging into steam generated like 500MB logs and lasted 10 minutes. I think ill try something different tomorrow to get another +relay log.
Any suggestions on what to look for or how to find the spot which is troubling us will make me look more enthuastic after whats wrong tomorrow
The Proble which is bugging me now is this: 2010-08-24 01:44:25 [ 71] [DEBUG ] PatchDownloader2.cpp (358) : current version 0002 2010-08-24 01:44:25 [ 71] [DEBUG ] PatchDownloader2.cpp (436) : I have the latest version, no need to patch fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority err:ntdll:RtlpWaitForCriticalSection section 0x33e5e8 "?" wait timed out in thread 003f, blocked by 0042, retrying (60 sec) fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority fixme:secur32:schan_InitializeSecurityContextW Using hardcoded "NORMAL" priority
Oh, and before I forget - I have a full version of the game. From what I know, the demo uses the same launcher and DRM though, so my findings should be relevant to it as well.
<aol/>, steam version. -mc
http://bugs.winehq.org/show_bug.cgi?id=22064
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net
--- Comment #47 from Anastasius Focht focht@gmx.net 2010-08-24 13:53:31 --- Hello,
--- quote --- c0000005 is a crash. Perhaps this is a red herring, but I wonder whether this crash is somewhere in a thread which should have been receiving data, which causes it never to receive it? I suspect someone willing to disassemble the app and debug the crash that way will get further with this than I. --- quote ---
well, I had a look at it ;-)
First, you can greatly reduce complexity by starting only the launcher with useful arguments:
--- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/Ubisoft/Ubisoft Game Launcher
$ wine ./UbisoftGameLauncher.exe -prodid 17 -gameversion 704 -lng en-US -nohttpproxy -orbitcookie 666 --- snip ---
Determine the exact values for your game using +relay or +process by starting the main game executable once.
While playing with the launcher I found additional useful command line arguments:
--- snip --- -httpproxy [proxy] -nohttpproxy -nowatchdog -orbitcookie [int] -orbitdroptimeout [seconds] -gameexe [path_base64_encoded_string] -satellites ip1:port1,ip2:port2 (note will crash the launcher if not valid format) -satellite_list_url [url] -orbitdev (use "mdc-dev-orbt-mgmt01.ubisoft.com") -orbituat (use "mdc-uat-orbt-lnx01.ubisoft.com" [defaults: static3.cdn.ubi.com/orbit and ubisoft-orbit.s3.amazonaws.com]) --- snip ---
Additional log files created in launcher folder:
--- snip --- launcher_log.txt orbitdll_game_log.txt orbitdll_launcher_log.txt --- snip ---
First there are notable 0x406D1388 exceptions (EXCEPTION_NAME_THREAD) which the ubisoft/orbit framework (ubiorbitapi_r2.dll) raises to give their worker threads meaningful names (the devs probably use Visual Studio).
Names given using EXCEPTION_NAME_THREAD:
"ServerBox - Resolver" - DNS resolver thread (gethostbyname) "Network Monitor" - (unknown how connections are "monitored") "NamedPipeConnection" - worker, reads from a named pipe ("\\.\pipe\orbit_ipc_pipe"), seems more like an in-process "IPC" mechanism "ServerBox - WorkerThread" - listens for data on sockets using I/O completion port (overlapped socket I/O)
The crash is in "ServerBox" socket receiver worker thread in some kind of memcpy() to copy received (and decrypted) payload(s) to other app internal buffers.
The "src" parameter of the copy routine is bogus at the time of the crash. It pointed to the last bytes of mapped ntdll.dll. The "memcpy" caller passed 1000 byte count hence it touched the next page after ntdll.dll which is of course not mapped, hence the read fault.
Upon reception of message, the receiver worker thread decrypts the message payload (if encrypted), calling secur32.DecryptMessage:
Without +relay channel:
--- snip --- ... 001e:trace:secur32:DecryptMessage 0x4d6c14 0xbde94c 0 (nil) 001e:trace:secur32:schan_DecryptMessage context_handle 0x1b9490, message 0xbde94c, message_seq_no 0, quality (nil) 001e:trace:secur32:dump_buffer_desc Buffer desc 0xbde94c: 001e:trace:secur32:dump_buffer_desc buffer 0: cbBuffer 26, BufferType 0x1 pvBuffer 0xbde8b0 001e:trace:secur32:dump_buffer_desc buffer 1: cbBuffer 0, BufferType 0 pvBuffer (nil) 001e:trace:secur32:dump_buffer_desc buffer 2: cbBuffer 0, BufferType 0 pvBuffer (nil) 001e:trace:secur32:dump_buffer_desc buffer 3: cbBuffer 0, BufferType 0 pvBuffer (nil) ... 001e:trace:secur32:schan_DecryptMessage Received 5 bytes --- snip ---
Now with +relay enabled (leading to crash):
--- snip --- ... 001d:trace:secur32:DecryptMessage 0x4d6c7c 0x9de94c 0 (nil) 001d:trace:secur32:schan_DecryptMessage context_handle 0x1cc820, message 0x9de94c, message_seq_no 0, quality (nil) 001d:trace:secur32:dump_buffer_desc Buffer desc 0x9de94c: 001d:trace:secur32:dump_buffer_desc buffer 0: cbBuffer 26, BufferType 0x1 pvBuffer 0x9de8b0 001d:trace:secur32:dump_buffer_desc buffer 1: cbBuffer 10348896, BufferType 0 pvBuffer 0x7bc914ba 001d:trace:secur32:dump_buffer_desc buffer 2: cbBuffer 29, BufferType 0 pvBuffer 0x7b8865b6 001d:trace:secur32:dump_buffer_desc buffer 3: cbBuffer 1, BufferType 0 pvBuffer 0x4d6c40 ... 001d:trace:secur32:schan_DecryptMessage Received 5 bytes ... 001d:Ret secur32.DecryptMessage() retval=00000000 ret=10052862 --- snip ---
Buffer index 1 and 2 contain completely bogus values due to changed stack layout (relay thunks). The app obviously didn't initialize all descriptor fields explicitly. A bit later, when the decrypted buffer payloads are copied:
--- snip --- 001d:trace:seh:raise_exception code=c0000005 flags=0 addr=0x1001d67a ip=1001d67a tid=001d 001d:trace:seh:raise_exception info[0]=00000000 001d:trace:seh:raise_exception info[1]=7bcb6000 001d:trace:seh:raise_exception eax=7bcb6292 ebx=009b9f70 ecx=000000a5 edx=00000000 esi=7bcb5ffe edi=004fe4e8 001d:trace:seh:raise_exception ebp=009de87c esp=009de874 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010202 001d:trace:seh:call_vectored_handlers calling handler at 0x689a12d0 code=c0000005 flags=0 001d:trace:seh:call_vectored_handlers handler at 0x689a12d0 returned 0 001d:trace:seh:call_stack_handlers calling handler at 0x10077f05 code=c0000005 flags=0 --- snip ---
esi=7bcb5ffe -> next dword touches unmapped page
I zeroed out the byte count for each unused buffer in "dlls/secur32/schannel.c:schan_DecryptMessage" and it helped. With that fix you can fully use +relay (with the "UbisoftGameLauncher.exe" launcher shortcuts I gave above).
Regards
http://bugs.winehq.org/show_bug.cgi?id=22064
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net Component|-unknown |secur32
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #48 from Mikko Rasa tdb@tdb.fi 2010-08-29 06:32:04 CDT --- Some new information, although no real progress yet:
As the OutputDebugString suggests, the launcher indeed gets a timeout with network communications. It sets up an overlapped WSARead operation, which never completes - apparently because nothing was sent to the server! I used tcpdump to see what's happening on the network, and got this (zero-length packets omitted):
14:12:16.562867 IP marmot.tdb.fi.40662 > 94.236.62.146.13000: Flags [P.], seq 1:94, ack 1, win 92, options [nop,nop,TS val 12889599 ecr 0], length 93 14:12:16.617338 IP 94.236.62.146.13000 > marmot.tdb.fi.40662: Flags [P.], seq 1:1283, ack 94, win 65442, options [nop,nop,TS val 69700319 ecr 12889599], length 1282 14:12:16.619829 IP marmot.tdb.fi.40662 > 94.236.62.146.13000: Flags [P.], seq 94:404, ack 1283, win 132, options [nop,nop,TS val 12889656 ecr 69700319], length 310 14:12:16.676744 IP 94.236.62.146.13000 > marmot.tdb.fi.40662: Flags [P.], seq 1283:1326, ack 404, win 65132, options [nop,nop,TS val 69700320 ecr 12889656], length 43 14:12:16.854161 IP 94.236.62.146.13000 > marmot.tdb.fi.40662: Flags [P.], seq 1326:1352, ack 404, win 65132, options [nop,nop,TS val 69700321 ecr 12889753], length 26
On windows, the sequence looks like this instead:
18:10:14.448346 IP marmot.tdb.fi.1062 > 94.236.62.145.13000: Flags [P.], seq 1:78, ack 1, win 65535, length 77 18:10:14.504443 IP 94.236.62.145.13000 > marmot.tdb.fi.1062: Flags [P.], seq 1:1283, ack 78, win 65458, length 1282 18:10:14.505222 IP marmot.tdb.fi.1062 > 94.236.62.145.13000: Flags [P.], seq 78:388, ack 1283, win 64253, length 310 18:10:14.564935 IP 94.236.62.145.13000 > marmot.tdb.fi.1062: Flags [P.], seq 1283:1326, ack 388, win 65148, length 43 18:10:14.743365 IP 94.236.62.145.13000 > marmot.tdb.fi.1062: Flags [P.], seq 1326:1352, ack 388, win 65148, length 26 18:10:14.744208 IP marmot.tdb.fi.1062 > 94.236.62.145.13000: Flags [P.], seq 388:426, ack 1352, win 64184, length 38 18:10:14.875979 IP 94.236.62.145.13000 > marmot.tdb.fi.1062: Flags [P.], seq 1352:1385, ack 426, win 65110, length 33
After this, the launcher closes the connection and opens another to a different server, with a similar exchange of packets, before going on to do some more complex stuff.
Now then, what component should send that missing packet and why is it not being sent?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #49 from Mikko Rasa tdb@tdb.fi 2010-08-29 09:12:21 CDT --- Created an attachment (id=30464) --> (http://bugs.winehq.org/attachment.cgi?id=30464) A program that emulates UGL connecting sequence
Using +secur32 output and MSDN I made a program that emulates the connecting sequence of the Ubisoft Game Launcher. Output in wine:
InitializeSecurityContext status 590610 Attributes 0 Output buffer contains 93 bytes Received 1282 bytes InitializeSecurityContext status 590610 Attributes 0 Output buffer contains 310 bytes Received 43 bytes InitializeSecurityContext status 0 Received 26 bytes DecryptMessage status 0 Decrypted data (5 bytes): 00 00 00 00 30
Output in windows:
AcquireCredentialsHandle status 0 InitializeSecurityContext status 590610 Attributes c01c Output buffer contains 77 bytes Received 1282 bytes InitializeSecurityContext status 590610 Attributes 801c Output buffer contains 310 bytes Received 43 bytes InitializeSecurityContext status 0 Received 26 bytes DecryptMessage status 0 Decrypted data (5 bytes): 17 03 01 00 15
There are several differences: attributes reported by InitializeSecurityContext, the size of the initial packet, and most importantly, the actual data that is received. Obviously the launcher isn't going to be happy if it gets the wrong data from the server. Could we be using the wrong cipher or something?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #50 from Hans Leidekker hans@meelstraat.net 2010-08-29 09:53:01 CDT --- In my testing I have found that Windows always fills a header buffer, a data buffer and then a trailer buffer in DecryptMessage. It optionally returns another data buffer when there's more data to be decrypted than the supplied buffer can hold.
Wine currently does not do any of that, which might explain what you're seeing.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #51 from Mikko Rasa tdb@tdb.fi 2010-08-29 10:19:17 CDT --- Thanks, that was a vital piece of information. On windows, pBuffers[1] indeed contains the same data as pBuffers[0] does in wine. Apparently the launcher is hardcoded to look for the decrypted data in pBuffers[1].
I don't know how to fix Wine properly, but I made a totally ugly hack to copy the first buffer into the second, and this was enough to make the launcher happy:
--- BEGIN PATCH --- diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c index 7a3bb3c..8a607a1 100644 --- a/dlls/secur32/schannel.c +++ b/dlls/secur32/schannel.c @@ -1216,6 +1224,9 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle buffer->cbBuffer = received; HeapFree(GetProcessHeap(), 0, data);
+ if(idx==0) + message->pBuffers[1] = message->pBuffers[0]; + return SEC_E_OK; }
--- END PATCH ---
Now to figure out why Settlers 7 shows only a white screen in place of the menu and crashes shortly after.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #52 from Mikko Rasa tdb@tdb.fi 2010-08-29 12:45:10 CDT --- The white screen problem was apparently fixed by increasing the amount of VRAM in wine registry. I just finished playing a skirmish round without much problems. There was some strange graphics corruption at one point but going to the trade screen and back fixed it.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #53 from Berillions berillions@gmail.com 2010-08-29 15:02:55 CDT --- (In reply to comment #51)
--- BEGIN PATCH --- diff --git a/dlls/secur32/schannel.c b/dlls/secur32/schannel.c index 7a3bb3c..8a607a1 100644 --- a/dlls/secur32/schannel.c +++ b/dlls/secur32/schannel.c @@ -1216,6 +1224,9 @@ static SECURITY_STATUS SEC_ENTRY schan_DecryptMessage(PCtxtHandle context_handle buffer->cbBuffer = received; HeapFree(GetProcessHeap(), 0, data);
- if(idx==0)
message->pBuffers[1] = message->pBuffers[0];- return SEC_E_OK;
}
--- END PATCH ---
Hello,
Thanks you for the patch but i have an error when i try to apply it in Wine source. When i launch "patch -p1 < schannel.patch", i have this error message :
berillions@debian:~/Desktop/wine-1.3.1$ patch -p1 < schannel.patch patching file secur32/schannel.c patch: **** malformed patch at line 6: schan_DecryptMessage(PCtxtHandle context_handle)
Thanks for your help
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #54 from Mikko Rasa tdb@tdb.fi 2010-08-29 15:07:03 CDT --- Created an attachment (id=30472) --> (http://bugs.winehq.org/attachment.cgi?id=30472) Dirty hack
The line patch is complaining about was supposed to be a continuation of the previous one. Apparently it isn't a good idea to paste patches, even short ones, in the comment body. I've attached it to this message instead. As a bonus, you can apply it directly with git am.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #55 from Berillions berillions@gmail.com 2010-08-29 15:21:30 CDT --- (In reply to comment #52)
The white screen problem was apparently fixed by increasing the amount of VRAM in wine registry.
Thanks Mikko, I have an other question. How did you increase it ine the registry (VRAM) ?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #56 from Berillions berillions@gmail.com 2010-08-29 16:57:41 CDT --- Created an attachment (id=30474) --> (http://bugs.winehq.org/attachment.cgi?id=30474) Screen 1
Mikko,
You are my heroes. With your hack, it's possible to play at Assassin's Creed without no-cd patch.
Look the screen. It's French so i explain for you.
On the Screen n°1, it's the windows to connect me at the Ubisoft Server with my ID and password.
After, the connection succeeded and play correctly. I found my savegame when i played on Windows.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #57 from Mikko Rasa tdb@tdb.fi 2010-08-29 23:33:12 CDT --- VRAM size can be set from HKCU\Software\Wine\Direct3D\VideoMemorySize. Wine has some code to guess it based on OpenGL vendor and renderer strings, but if it doesn't recognize your card, it falls back to a rather low amount.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #58 from Wylda wylda@volny.cz 2010-08-30 05:06:05 CDT ---
Great that at least hack exists. Thanks. I do not now, if anyone of you use nick Max in AppDB, but please do not fill a haxed version of wine in AppDB. If there is a problem, i can look into AppDB seeing that 1.3.1 being platinum, but that's not true. For 1.3.1 is garbage. Well it's written in extra comment, but i often look just on the table listing 20 versions and don't have time to read each and every comment when working on bugzilla.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #59 from Berillions berillions@gmail.com 2010-08-30 05:18:03 CDT --- Hello Mikko,
I have a question. Your patch is a "hack" so it will never be in Wine >= 1.3.2 ? I should to patch the Wine source when a new version will release ?
Thanks (sorry for my english, i'm french)
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #60 from Mikko Rasa tdb@tdb.fi 2010-08-30 08:52:28 CDT --- @Wylda: I don't use that nick, although I did submit a report with a silver rating. Could a separate rating be added for "works with modifications to wine source"? I'm sure I'm not the only one who won't mind hacking a bit to get games working.
@Berillions: That hack was the fastest way to make it work, and I don't consider it to be production quality. I'm looking into creating a better patch that can be submitted for inclusion in the official source. If wine-1.3.2 gets released before I can manage that, then yes, you will need to apply the patch again.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #61 from Hans Leidekker hans@meelstraat.net 2010-08-30 09:16:49 CDT --- Created an attachment (id=30483) --> (http://bugs.winehq.org/attachment.cgi?id=30483) secur32: Return header and trailer buffer from DecryptMessage (schannel).
Does this patch work for you?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #62 from Berillions berillions@gmail.com 2010-08-30 10:15:12 CDT --- (In reply to comment #61)
Created an attachment (id=30483)
--> (http://bugs.winehq.org/attachment.cgi?id=30483) [details]
secur32: Return header and trailer buffer from DecryptMessage (schannel).
Does this patch work for you?
Hello,
I tried your patch. It works !!! Launcher OK, no problem to connect me at the Ubisoft Server to play.
Thanks :)
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #63 from Berillions berillions@gmail.com 2010-08-30 10:40:59 CDT --- I forget to add that the online save doesn't works. Unable to upload the savegame to the Ubisoft Server.
But, there is an offline save of your game in this directory : ~/home/USER/.wine/drive_c/Program Files/Ubisoft/Ubisoft Game Launcher/storage
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #64 from Mikko Rasa tdb@tdb.fi 2010-08-30 11:36:00 CDT --- While Hans's patch indeed works in this case, it doesn't quite match what windows does. The header should stay in the buffer the input data was in, regardless of its index. If there's extra data in the input buffer, a buffer of type SECBUFFER_EXTRA should also be filled. The validation code is lacking a check for multiple buffers as well, and hardcoding the MAC size might be bad.
I've prepared a set of patches which I believe are good quality and will send them off to the proper place shortly.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #65 from Hans Leidekker hans@meelstraat.net 2010-08-30 11:45:55 CDT ---
The header should stay in the buffer the input data was in, regardless of its index.
That doesn't match my findings. Moving the data buffer around gave me the impression that native stores decrypted data in the first empty buffer then uses the next two empty buffers for header and trailer, possibly reusing the original data buffer index.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #66 from Mikko Rasa tdb@tdb.fi 2010-08-30 11:49:37 CDT --- I changed my test program to feed in the data in the last buffer, and this is what I got back:
Decrypted buffer 0 (5 bytes @003E60B5, type 1): 00 00 00 00 30 Decrypted buffer 1 (16 bytes @003E60BA, type 6): cd 91 b4 75 83 57 55 f3 ba cf a1 ec b1 be ad 5c Decrypted buffer 2 (0 bytes @00000000, type 0): Decrypted buffer 3 (5 bytes @003E60B0, type 7): 17 03 01 00 15
It's definitely using the original data buffer as header and the first two empty buffers for data and trailer.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #67 from Hans Leidekker hans@meelstraat.net 2010-08-31 02:56:08 CDT ---
It's definitely using the original data buffer as header and the first two empty buffers for data and trailer.
You're right, I mixed up header and trailer (likely because they are numbered 7 and 6 respectively). I get:
Input: buffer index buffer type 0 empty 1 empty 2 empty 3 data
Output: buffer index buffer type 0 data 1 trailer 2 empty 3 header
Which confirms your results.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #68 from Berillions berillions@gmail.com 2010-08-31 04:40:39 CDT --- Hello,
The patch works correctly for 2 games : - Assassin's Creed 2 - Prince of Persia : The Forgotten Sands
But, i tried to play at "Splinter Cell : Conviction" and wine crash after to update the game.
I don't know if it's a DRM problem or other so i post the link to my post on the Wine Forum : http://forum.winehq.org/viewtopic.php?p=48955#48955
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #69 from Mikko Rasa tdb@tdb.fi 2010-09-01 13:10:29 CDT --- Ubisoft released a patch (version 0124) to their launcher today that breaks it again in wine. I haven't quite got to the bottom of the issue yet, but the relevant change seems to be that they're now using GetQueuedCompletionStatus instead of PeekNamedPipe to watch a communication pipe (called \.\pipe\orbit_ipc_pipe). Somehow the threads get into a state where they just call GetQueuedCompletionStatus infinitely when one of them should continue communications with the server.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #70 from Berillions berillions@gmail.com 2010-09-03 04:46:10 CDT --- (In reply to comment #69)
Ubisoft released a patch (version 0124) to their launcher today that breaks it again in wine. I haven't quite got to the bottom of the issue yet, but the relevant change seems to be that they're now using GetQueuedCompletionStatus instead of PeekNamedPipe to watch a communication pipe (called \.\pipe\orbit_ipc_pipe). Somehow the threads get into a state where they just call GetQueuedCompletionStatus infinitely when one of them should continue communications with the server.
It's possible de resolve this problem ?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #71 from Mikko Rasa tdb@tdb.fi 2010-09-03 08:46:14 CDT --- (In reply to comment #70)
It's possible de resolve this problem ?
Possible, yes. How much time it will take is another matter. I'm no expert in win32 programming, so there's much trial and error involved before I can identify and fix the problem. Someone more knowledgeable of the I/O subsystem might be able to do it faster.
Meanwhile, the 0121 version of the launcher still works if you modify the version.txt file to make it think it's version 0124 and not update itself.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #72 from Mikko Rasa tdb@tdb.fi 2010-09-15 11:44:22 CDT --- Created an attachment (id=30768) --> (http://bugs.winehq.org/attachment.cgi?id=30768) +relay log with UGL version 0125
Ubisoft released a new version (0125) of the launcher recently. Version 0121 appears to no longer work. On windows the launcher seems to send two packets before receiving a reply from the server. On wine it sends just one and starts waiting for a reply which never arrives.
Attached is a +relay log from this newest version. I have no immediate clue to what's wrong. I'll be happy to provide further logs on request.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #73 from Berillions berillions@gmail.com 2010-09-27 12:05:56 CDT --- (In reply to comment #72)
Created an attachment (id=30768)
--> (http://bugs.winehq.org/attachment.cgi?id=30768) [details]
+relay log with UGL version 0125
Ubisoft released a new version (0125) of the launcher recently. Version 0121 appears to no longer work. On windows the launcher seems to send two packets before receiving a reply from the server. On wine it sends just one and starts waiting for a reply which never arrives.
Attached is a +relay log from this newest version. I have no immediate clue to what's wrong. I'll be happy to provide further logs on request.
How to help you Mikko ?
http://bugs.winehq.org/show_bug.cgi?id=22064
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #74 from Wylda wylda@volny.cz 2010-09-27 13:52:30 CDT ---
Actually this is fixed. Tested under wine-1.3.3-282-g440cf08 with results:
* Settlers 7 Demo - after installation on first run, the game is updated to v1.04.1214 and runs. During that Ubisoft updater is also updated from version 0115 to 0125. Game can be run even with updater version 0125.
* Assassion Creed 2 - i backup Ubisoft updater for sure. When this gets updated to v0125 AC2 freezes in a loop. But rewriting ini file from 0121 to 0125 will not update the updater and game runs :-)
In both games i can see graphical issus: * AC - semi-transparent character (remembered me bug 24067)
* Settlers 7 - river displayed in initial menu shows itself like black and white dots...
Great work Mikko!
BTW: Which patches are necessary for make it run. I'm thinking of putting them on an older wine versions (if possible) and making some graphical regression tests.
Remaining issues should be address by separate bug reports.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #75 from Wylda wylda@volny.cz 2010-09-27 14:17:37 CDT ---
Settlers 7 graphical issue continues in bug 24544.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #76 from Mikko Rasa tdb@tdb.fi 2010-09-27 15:42:57 CDT --- Interesting, it does not work for me even with the exact same wine version. I'll have to try reinstalling to a clean wineprefix tomorrow (I tried with one that had the demo pre-installed but no other modifications).
The following commits in git are relevant:
a4435e3 - makes launcher patching work
9320819 - allows the launcher to successfully download files
b424b34, 149ffe1 - fix communications with Ubisoft server
b335e94 - allows a new account to be created in the launcher
506af92 - related to the previous one, unsure if this was needed
Then there's something after f2377e8 that apparently fixes the problems with 0124 and later launcher versions for you, but I'm not sure which commit it is. You'll need to bisect this one. Let me know if you find it.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #77 from Wylda wylda@volny.cz 2010-09-28 01:03:56 CDT --- (In reply to comment #76)
Then there's something after f2377e8 that apparently fixes the problems with 0124 and later launcher versions for you, but I'm not sure which commit it is.
To be sure, we are talking about the same. * Settler 7's launcher v0125 works * Assassin Creed 2's launcher v0125 doesn't works
So you want to bisect a first good commit for Settler 7 and launcher 0125?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #78 from Mikko Rasa tdb@tdb.fi 2010-09-28 04:48:44 CDT --- Yes, that's the bisect I was talking about.
That's a very interesting discrepancy between the two games. Did you use existing installations or make new ones with latest wine? I assume the games are in different wineprefixes? Can you run diff on the Ubisoft Game Launcher directories to see if they match (after both are updated to version 0125)?
What happens if you first install Settlers 7 Demo with its working launcher in a clean wineprefix, patch it, and then Assassin's Creed 2 in the same wineprefix? I'd assume the latter would detect an existing launcher and not install its own, thus using the working one.
What kind of loop did you mean with Assassin's Creed 2? For me, the launcher simply gets stuck with the spinning circle, apparently waiting for an event which is never delivered.
It's also interesting that UGL 0121 still works for you with AC2. Could you check this with Settlers 7 as well? For me, version 0121 refuses to communicate properly with the server ever since 0125 was released.
Can you do a +winhttp,+winsock trace to see if the games are using the same servers?
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #79 from Wylda wylda@volny.cz 2010-09-28 05:47:49 CDT ---
Really sorry Mikko for the mess i did here :-/ Sure i had to make a mistake by rewriting version from 0115 into 0125. And when verified, if everything is OK look into version and saw 0125 - bing 0125 is working, but actually running 0115. Anyway i think that originally reported problem is fixed.
Back to your question - yes 0115 and 0121 are working for me. 0125 is not.
I have an idea but still fail to realize it :-/ I compared secure32 traces from 0121 and 0125. The difference is, that there is an extra EncryptMessage in 0125. So maybe 0125 gathers some new machine info sends it to the server and he doesn't like it because of wine so the connection dies. Maybe i'm wrong...
So what i'm trying to do, is setup SSL webserver (done) + ceriticate&private key (done) + use ssldump with SSL's webserver private key (so it will easily decrypt the traffic sent by UGL to my private server and also i can compare it with WinXP --partly works) + reroute the trafic for satellitelist.txt's ip addresses to my server (or atleast assign all these ip addresses from the list to my eth0).
Well i still fails with ssldump. This should work for clasic browser connection, but i unfortunately don't see content of the traffic:
ssldump -Ad -k /etc/apache2/ssl/cert_and_private_key.pem -i eth0 port 443
What else i do (hint by Anastasius) - i run just the launcher - it seems enough to see if it works:
wine UbisoftGameLauncher.exe -prodid 17 -gameversion 704 -orbitcookie 666
This offers me login screen for 0115 and 0121, but hungs on 0125 as normally.
Also i noticed, that it's enough to replace "UGL" exe and it's ubiorbitapi_r2.dll. No need to replace the whole UGL folder. So i can easily shift between different versions.
What do you think about the ssldump? I give up for this week. Hope that next one or two i might get fresh idea what can be wrong about ssldump. Feel free to continue in between or warn me that i'm wasting time ;)
http://bugs.winehq.org/show_bug.cgi?id=22064
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #80 from Alexandre Julliard julliard@winehq.org 2010-10-01 13:57:13 CDT --- Closing bugs fixed in 1.3.4.
http://bugs.winehq.org/show_bug.cgi?id=22064
--- Comment #81 from Christoph Korn c_korn@gmx.de 2010-10-01 16:53:48 CDT --- I opened bug 24590 about the spinning circle problem at the splash screen.
http://bugs.winehq.org/show_bug.cgi?id=22064
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Fixed by SHA1| |b335e94788647afa013b5e58791 | |f176b2a459e38
-
wine-bugs＠winehq.org