https://bugs.winehq.org/show_bug.cgi?id=38134
Bug ID: 38134 Summary: Uplay v5.x: can't log in (Uplay hangs with the login screen) Product: Wine Version: 1.7.37 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: gyebro69@gmail.com Distribution: ---
Created attachment 50830 --> https://bugs.winehq.org/attachment.cgi?id=50830 terminal output
Since the latest Uplay client update (19th Feb 2015) I can't log in to Uplay because the client just hangs with 100% CPU usage after entering the email/password credentials. Tried with WinXP/Vista/Seven profiles with the same result. (Logging in works in a Windows XP guest running in Virtualbox.)
https://ubistatic3-a.akamaihd.net/orbit/launcher_installer/UplayInstaller.ex... UPlayInstaller.exe md5sum: df063b5902ef1b08458083f4ad63c672
Fedora 21 x86
https://bugs.winehq.org/show_bug.cgi?id=38134
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |https://ubistatic3-a.akamai | |hd.net/orbit/launcher_insta | |ller/UplayInstaller.exe
https://bugs.winehq.org/show_bug.cgi?id=38134
Yuri Shishenko yurishish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yurishish@gmail.com
--- Comment #1 from Yuri Shishenko yurishish@gmail.com --- (In reply to Béla Gyebrószki from comment #0)
Created attachment 50830 [details] terminal output
Since the latest Uplay client update (19th Feb 2015) I can't log in to Uplay because the client just hangs with 100% CPU usage after entering the email/password credentials. Tried with WinXP/Vista/Seven profiles with the same result. (Logging in works in a Windows XP guest running in Virtualbox.)
https://ubistatic3-a.akamaihd.net/orbit/launcher_installer/UplayInstaller.ex... UPlayInstaller.exe md5sum: df063b5902ef1b08458083f4ad63c672
Fedora 21 x86
For me uplay stucks on logging in screen with loading animation but it doesn't hangs and uses only 10-12% CPU.
Can you post network_info.txt log (c:/Program Files/Ubisoft/Ubisoft Game Launcher/logs/network_info.txt, don't forget to redact real MAC addresses)? For me it shows this:
Network summary: ! DNS Server may be unavailable or inaccessible.
Full log http://pastebin.com/2TYUAbe8
Although nslookup.exe works correctly. Also, it seems that this issue affects all wine versions, including 1.7.37.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #2 from Béla Gyebrószki gyebro69@gmail.com --- Network_info.txt under Linux/Wine (non-working): http://pastebin.com/GLkKtURC
The same info under Windows XP running in Vbox (working): http://pastebin.com/7SR11UjU
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #3 from Yuri Shishenko yurishish@gmail.com --- Yep, same results.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #4 from Bruno Jesus 00cpxxx@gmail.com --- Do I need a valid login to test?
The problem seems to be that the adapter does not have the DNS address set. We could fake it or try to get the real value somehow.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #5 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Bruno Jesus from comment #4)
Do I need a valid login to test?
The problem seems to be that the adapter does not have the DNS address set. We could fake it or try to get the real value somehow.
Yes, you need a Uplay account to test.
If I enter wrong name or password then I receive an error. It's only when I enter the correct name/password that Uplay hangs.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #6 from Yuri Shishenko yurishish@gmail.com --- Steps to reproduce: 1. Launch Uplay 2. Enter valid login credentials (uplay account is required) 3. Press Enter or press log in button
Expected result: Uplay main window opening
Actual result: Uplay stucks on login window with loading animation.
Seems that this issue affects Uplay only because, as i said before, nslookup.exe works correctly, and IE launched from the same wineprefix is able to load websites.
https://bugs.winehq.org/show_bug.cgi?id=38134
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #7 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Bruno Jesus from comment #4)
Do I need a valid login to test?
The problem seems to be that the adapter does not have the DNS address set. We could fake it or try to get the real value somehow.
Thats not the problem. I spend a bit time to look into this issue today, and by hacking a bit around in iphlpapi/iphlpapi_main.c I made the network_info.txt test pass. The whole output looks fine but the main issue (hangs while trying to login) still persists. I guess the failing network check could be splitted into a separate bug if someone cares about it. ;)
I somehow fear that the main issue is related to secur32 / gnutls. While the application is hanging it tries over and over to establish some schannel connection. Will investigate this a bit more during the next days.
https://bugs.winehq.org/show_bug.cgi?id=38134
Michael Müller michael@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |michael@fds-team.de
--- Comment #8 from Michael Müller michael@fds-team.de --- The problem only occurs with libgnutls28. If you use libgnutls26 instead, the login still works without issues. Seems like an upstream bug in gnutls. I try to track this down a bit more.
Please note that most distro packages have an explicit dependency on a specific version, so the only way to switch that is during compile time.
https://bugs.winehq.org/show_bug.cgi?id=38134
Berillions berillions@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |berillions@gmail.com
--- Comment #9 from Berillions berillions@gmail.com --- (In reply to Michael Müller from comment #8)
The problem only occurs with libgnutls28. If you use libgnutls26 instead, the login still works without issues. Seems like an upstream bug in gnutls. I try to track this down a bit more.
Please note that most distro packages have an explicit dependency on a specific version, so the only way to switch that is during compile time.
How do you use libgnutls26 instead of libgnutls28 ?
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #10 from Michael Müller michael@fds-team.de --- If you have the libgnutls26 library installed, you need to change the library name in dlls/secur32/schannel_gnutls.c.
You need to replace SONAME_LIBGNUTLS in the following line with "libgnutls.so.26".
----- libgnutls_handle = wine_dlopen(SONAME_LIBGNUTLS, RTLD_NOW, NULL, 0); -----
The actual library name may differ depending on your distribution. Alternatively, you can try to remove the development files for libgnutls28 and make sure that only those for libgnutls26 are installed. This should force configure to detect and link against the older library version.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #11 from Berillions berillions@gmail.com --- (In reply to Michael Müller from comment #8)
The problem only occurs with libgnutls28. If you use libgnutls26 instead, the login still works without issues. Seems like an upstream bug in gnutls. I try to track this down a bit more.
Please note that most distro packages have an explicit dependency on a specific version, so the only way to switch that is during compile time.
libgnutls26 package is not available on Debian repository (in fact, only in Experimental). Do you have news about the possible bug into libgnutls28 ?
https://bugs.winehq.org/show_bug.cgi?id=38134
Konstantin Svist fry.kun@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fry.kun@gmail.com
--- Comment #12 from Konstantin Svist fry.kun@gmail.com --- Having the same problem with uplay. On Fedora 21; don't see the old gnutls library obviously available anywhere.
Note: easy way to test/replicate without having an account is to press "Create a new account" in the app's login window.
https://bugs.winehq.org/show_bug.cgi?id=38134
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |37076
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #13 from Berillions berillions@gmail.com --- Obviously, Wine's developper don't care about this bug. They don't search if it's possible to hack Wine or others possibilities ...
I'm happy to return to Windows to play at Windows's games...
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #14 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Berillions from comment #13)
Obviously, Wine's developper don't care about this bug. They don't search if it's possible to hack Wine or others possibilities ...
I'm happy to return to Windows to play at Windows's games...
You were provided with a workaround to try.
(In reply to Berillions from comment #11)
libgnutls26 package is not available on Debian repository (in fact, only in Experimental). Do you have news about the possible bug into libgnutls28 ?
I don't think it's true - https://packages.debian.org/search?keywords=libgnutls26. And you actually can install both of them at the same time, for both arches.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #15 from Berillions berillions@gmail.com --- (In reply to Nikolay Sivov from comment #14)
(In reply to Berillions from comment #13)
Obviously, Wine's developper don't care about this bug. They don't search if it's possible to hack Wine or others possibilities ...
I'm happy to return to Windows to play at Windows's games...
You were provided with a workaround to try.
Yes but libgnutls26 is an old version and i think that this package will be delete from Experimental when Debian Jessie will be release ...
On Fedora, Arch and others this package is not available.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #16 from Berillions berillions@gmail.com --- Hi,
I send a message in the Gnutls bugzilla. This is the answer from the developer : http://lists.gnutls.org/pipermail/gnutls-devel/2015-March/007511.html
-------------------
Hello, I tried to reproduce what you mention I don't see any issue in gnutls negotiating with the server. You can also see that by checking the wireshark log, as well as running wine while GNUTLS_DEBUG_LEVEL is set to something more than 6. It seems like the application (or wine) is in an infinite loop creating a client hello. I'd suggest to try to debug it further with the wine people, and if the issue concludes that gnutls fails to talk to some server then bring that here. As it is now I don't see any such issue and there is very little that can be done by gnutls for the issue you see.
You could also try comparing the wireshark logs from the version that works with the other that doesn't and try to spot the differences.
regards, Nikos
-------------------
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #17 from Berillions berillions@gmail.com --- Hi,
I received a new email from Nikos Mavrogiannopoulos, the GnuTLS developer. He tried to launch Uplay on wine with GnuTLS 2.12.24 and GnuTLS 3.3.13.
This is his log : Log with GnuTLS 3.3.13: http://pastebin.com/i9JfxaK6 Log with GnuTLS 2.12.24: http://pastebin.com/j2x9EB94
Her message : ------- The difference I see with kompare, is that the second session established follows a different path in 3.3.13 and after SECUR32_makeSecHandle, AcquireCredentialsHandleW is called, while in 2.12.x InitializeSecurityContextW is called. Then 2.12.24 completes the session while 3.3.13 starts a new one. None of the paths called rings a bell but someone of the wine team could have a clue what that difference means. -------
https://bugs.winehq.org/show_bug.cgi?id=38134
Nikos Mavrogiannopoulos nmav@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nmav@redhat.com
--- Comment #18 from Nikos Mavrogiannopoulos nmav@redhat.com --- One issue that I found is that this application is setting a server name of zero length and this confuses gnutls. I've submitted a fix that will be included in newer gnutls, but a fix in wine (attached) will allow it work with all gnutls versions.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #19 from Nikos Mavrogiannopoulos nmav@redhat.com --- Created attachment 51123 --> https://bugs.winehq.org/attachment.cgi?id=51123 fix for compatibility with apps that set a 0-length name
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #20 from Nikos Mavrogiannopoulos nmav@redhat.com --- I forgot to mention that the attached patch fixes the issue.
https://bugs.winehq.org/show_bug.cgi?id=38134
Michael Cronenworth mike@cchtml.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mike@cchtml.com
--- Comment #21 from Michael Cronenworth mike@cchtml.com --- (In reply to Nikos Mavrogiannopoulos from comment #19)
Created attachment 51123 [details] fix for compatibility with apps that set a 0-length name
http://wiki.winehq.org/SubmittingPatches
Just so that your work does not get lost. They don't apply patches from Bugzilla.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #22 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 51225 --> https://bugs.winehq.org/attachment.cgi?id=51225 patch
Please try the attached patch, it's based on original patch by Nikos Mavrogiannopoulos with the approach commented by Jacek Caban. I can't reproduce the bug myself.
https://bugs.winehq.org/show_bug.cgi?id=38134
--- Comment #23 from Béla Gyebrószki gyebro69@gmail.com --- (In reply to Bruno Jesus from comment #22)
Created attachment 51225 [details] patch
Please try the attached patch, it's based on original patch by Nikos Mavrogiannopoulos with the approach commented by Jacek Caban. I can't reproduce the bug myself.
The patch works here.
Fedora 21 gnutls-3.3.13-1.fc21.i686
https://bugs.winehq.org/show_bug.cgi?id=38134
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |0fbbb1297d4fc14e71ff76379ba | |0b80382e97edc Status|NEW |RESOLVED Component|-unknown |secur32 Resolution|--- |FIXED
--- Comment #24 from Béla Gyebrószki gyebro69@gmail.com --- Fixed by http://source.winehq.org/git/wine.git/commitdiff/0fbbb1297d4fc14e71ff76379ba...
https://bugs.winehq.org/show_bug.cgi?id=38134
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.41.
-
wine-bugs＠winehq.org