[Bug 27653] New: EVE Online responds with "Connection Failure: Handshake Error" on login attempt.
http://bugs.winehq.org/show_bug.cgi?id=27653
Summary: EVE Online responds with "Connection Failure: Handshake Error" on login attempt. Product: Wine Version: 1.3.23 Platform: x86-64 OS/Version: FreeBSD Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: naylor.b.david@gmail.com
Created an attachment (id=35361) --> (http://bugs.winehq.org/attachment.cgi?id=35361) Trace log with trace patch from #22355 (patch modified to avoid functional change)
EVE Online fails to log in with "Connection Failure: Handshake Error".
This has been reported on both FreeBSD -current and 8-stable when running a 32bit wine under a 64bit FreeBSD. Also, when applying the trace patch from bug #22355 the trace indicates it is not related to that error. (See attached for the trace with WINEDEBUG=iphlpapi with that patch applied).
My attempts to determine where the error occurs has been unsuccessful.
http://bugs.winehq.org/show_bug.cgi?id=27653
Wylda wylda@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #35361|application/octet-stream |text/plain mime type| | Attachment #35361|wine.trace |wine_trace.txt filename| |
--- Comment #1 from Wylda wylda@volny.cz 2011-06-29 16:09:02 CDT --- (From update of attachment 35361) Nextime please attach as a .txt file.
http://bugs.winehq.org/show_bug.cgi?id=27653
Nick Evans nevans@talkpoint.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from Nick Evans nevans@talkpoint.com 2011-06-30 09:52:56 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=27653
Hedgehog nbspjr@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nbspjr@gmail.com
--- Comment #3 from Hedgehog nbspjr@gmail.com 2011-10-30 04:06:58 CDT --- I encountered the same issue with eve-onine under freebsd-8.2-release amd64 I don't run wine from chrooted environment anymore, I use 32bit package instead. I removed eve-online so can't attach log now, but I'm installing the game client now and will post the log soon
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #4 from Hedgehog nbspjr@gmail.com 2011-11-05 04:04:38 CDT --- Created attachment 37311 --> http://bugs.winehq.org/attachment.cgi?id=37311 trace log without patches
this is an output in console when i'm trying to log in
command line: env WINEDEBUG=+iphlpapi,-d3d_surface,-d3d,-d3d_shader wine eve.exe
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #5 from Juan Lang juan.lang@gmail.com 2011-11-05 08:15:13 CDT --- What the iphlpapi log posted before showed is that iphlpapi is not the likely culprit, so getting more iphlpapi logs isn't all that useful. From the error description, I'd say it's more likely to be a problem with schannel. Please attach a +secur32 log.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #6 from Hedgehog nbspjr@gmail.com 2011-11-06 01:49:35 CST --- (In reply to comment #5)
What the iphlpapi log posted before showed is that iphlpapi is not the likely culprit, so getting more iphlpapi logs isn't all that useful. From the error description, I'd say it's more likely to be a problem with schannel. Please attach a +secur32 log.
Thanks for reply. I've enabled secur32 channel, but there was nothing new in output. Still the same iphlpapi trace logs at every login attempt. Just a note to let you know that the game displays news in the login window (fetched from server), server status and players count. Also I had no problems downloading and applying a patch by the eve itself. I mean, the game communicates with server just well, except logging in.
FreeBSD 8.2-RELEASE-p4 amd64 wine 1.3.23(not chrooted) environment: WINEDEBUG=+iphlpapi,+secur32,-d3d_surface,-d3d,-d3d_shader
is there anything else I can do to provide useful logs?
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #7 from Juan Lang juan.lang@gmail.com 2011-11-06 21:36:20 CST --- I took another glance at the logs, and I should have looked more closely before. This is curious: trace:iphlpapi:GetAdaptersInfo pAdapterInfo 0x0, pOutBufLen 0x33ad20 (snip) trace:iphlpapi:GetAdaptersInfo returning 111 trace:iphlpapi:GetAdaptersInfo pAdapterInfo 0x766f930, pOutBufLen 0x33ad20 (snip) trace:iphlpapi:GetAdaptersInfo returning 14
GetAdaptersInfo is never succeeding: it would return 0 on success. Instead, it's failing with ERROR_OUTOFMEMORY on the second call. This only appears to happen if getNonLoopbackInterfaceTable fails. Perhaps if_nameindex() doesn't work correctly?
You aren't by any chance running this in a chroot environment, are you?
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #8 from Hedgehog nbspjr@gmail.com 2011-11-07 09:39:10 CST --- (In reply to comment #7)
You aren't by any chance running this in a chroot environment, are you?
I'm using 32bit wine package by David Naylor. AFAIK, it uses x86 compatibility built into kernel. However, I have a working system in chroot, but I made that directory inaccessible before launching eve. By the way, after that I tried run wine from chroot ant get the same iphlpapi trace. Maybe it's related? There is ifconfig output from chrooted env: vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=82808<VLAN_MTU,WOL_UCAST,WOL_MAGIC> ether xx:xx:xx:xx:xx:xx inet xx.xx.xx.xx netmask 0xfffffc00 broadcast xx.xx.xx.xx nfe0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC> ether xx:xx:xx:xx:xx:xx inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.xx plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> metric 0 mtu 1500 lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet 127.0.0.1 netmask 0xff000000 I can't see anything wrong in interfaces list
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #9 from Juan Lang juan.lang@gmail.com 2011-11-07 09:48:51 CST --- Please run outside of a chroot environment first. Bug 22355, which has the same symptom, is a bug in FreeBSD in chroot environments. (It was supposedly fixed in FreeBSD 8-stable, but it could have regressed.)
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #10 from Hedgehog nbspjr@gmail.com 2011-11-07 10:07:14 CST --- (In reply to comment #9)
Please run outside of a chroot environment first. Bug 22355, which has the same symptom, is a bug in FreeBSD in chroot environments. (It was supposedly fixed in FreeBSD 8-stable, but it could have regressed.)
Thanks for the reply.
I've launched it from chroot just to compare trace logs, forgive me if it was unclear. In bug 22355 the issue was related to missing interface names under chroot and it has been fixed as you can see in the ifconfig output in my previous post. The result of ifconfig command was pretty same in both chroot and host.
But before that, I didn't use chroot to launch wine. Actually, now I completely wiped out all my chroot stuff and starting eve from the x86 package installed into main system. Still no luck. I even created a new clean prefix, except that I had to install few dx9 dlls overrides + corefonts to start eve.
I'm pretty sure that I was able to play eve like year ago or more on my box.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #11 from Juan Lang juan.lang@gmail.com 2011-11-07 11:04:00 CST --- Right, but 22355 was about missing interface names, but the current symptom appears to be that if_nameindex is failing, which is rather odd. Let me attach a little test program; please compile it and run it and attach the output. (Curiously, for me on Ubuntu, it says lo is not a loopback interface, but that's a different issue.)
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #12 from Juan Lang juan.lang@gmail.com 2011-11-07 11:04:43 CST --- Created attachment 37354 --> http://bugs.winehq.org/attachment.cgi?id=37354 if_nameindex test
Please attach the output from this, or compile errors if it doesn't compile for you.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #13 from Hedgehog nbspjr@gmail.com 2011-11-07 12:16:18 CST --- (In reply to comment #12)
Created attachment 37354 [details] if_nameindex test
Please attach the output from this, or compile errors if it doesn't compile for you.
I've got warning upon compilation: $ gcc if_nameindex.c if_nameindex.c: In function 'isLoopbackInterface': if_nameindex.c:16: warning: incompatible implicit declaration of built-in function 'strcpy'
$ ./a.out vr0 is not a loopback interface nfe0 is not a loopback interface plip0 is not a loopback interface lo0 is not a loopback interface
is that's the problem? seems that it unable to find loopback interface
when i included string.h the warning gone, but output remains the same as above #include <string.h>
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #14 from Juan Lang juan.lang@gmail.com 2011-11-07 12:32:17 CST --- Created attachment 37355 --> http://bugs.winehq.org/attachment.cgi?id=37355 Patch: trace return value from getIPAddrTable
Okay, perhaps you could attach a +iphlpapi trace with this patch attached? It might be another function that's failing.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #15 from Hedgehog nbspjr@gmail.com 2011-11-07 13:36:42 CST --- (In reply to comment #14)
Created attachment 37355 [details] Patch: trace return value from getIPAddrTable
Okay, perhaps you could attach a +iphlpapi trace with this patch attached? It might be another function that's failing.
Sorry, I don't know how to build x86 wine without chroot, I'm used to install David Naylor's package. But I still can attach a log of wine in chroot with your patch. Hope it will help. Also, there is 1.3.11 wine in chroot. If you want the trace from actual release, I could compile it tomorrow.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #16 from Hedgehog nbspjr@gmail.com 2011-11-07 13:39:42 CST --- Created attachment 37359 --> http://bugs.winehq.org/attachment.cgi?id=37359 +iphlpapi trace (Patch: trace return value from getIPAddrTable)
http://bugs.winehq.org/show_bug.cgi?id=27653
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37355|0 |1 is obsolete| |
--- Comment #17 from Juan Lang juan.lang@gmail.com 2011-11-07 14:29:22 CST --- Created attachment 37364 --> http://bugs.winehq.org/attachment.cgi?id=37364 Patch: add more traces
I'd prefer not to run in a chroot environment, or at least to compare a chroot environment to a non-chroot one, but let's assume it's not the cause of the issue for now. Please attach a +iphlpapi trace with the following patch applied instead: it looks like iotcl's failing for SIOCGIFCONF, and it might finally be time to replace that crufty old code with something based on getifaddrs instead, but I'd like to confirm a little what's happening first.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #18 from David Naylor naylor.b.david@gmail.com 2011-11-07 14:31:26 CST --- To compile the wine package I use a i386 chroot. The patch that I posted for that package just packages all the needed 32-bit libraries and ensure the 32-bit binary can find them in a 64-bit dominant environment.
Make sure UNAME_p, UNAME_m and MACHINE environment variables are set to i386 in the chroot.
If you are unable to compile wine I can give it a go tomorrow...
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #19 from Hedgehog nbspjr@gmail.com 2011-11-09 04:42:17 CST --- Created attachment 37398 --> http://bugs.winehq.org/attachment.cgi?id=37398 +iphlpapi trace (Patch: add more traces)
there is an +iphlpapi trace with patch. first I tried to run it in chroot, then I just replaced an existing iphlpapi.dll.so with that new one built with patch, then launched the game outside chroot. I attached both logs so you can compare it. as for me, its equal to each other.
I assume, that you were right, Juan Lang: err:iphlpapi:enumIPAddresses ioctl failed: 14 (Bad address)
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #20 from Juan Lang juan.lang@gmail.com 2011-11-09 11:24:15 CST --- Okay, thanks very much for testing in both chroot and non-chroot environments. We can safely rule that one out. If someone could change the component to iphlpapi, that would be nice. (Or, if someone could give this account of mine more privs, that'd also be nice.)
I'm a sporadic contributor these days, so I don't have an ETA for a fix yet. If someone want to beat me to it, by all means.
http://bugs.winehq.org/show_bug.cgi?id=27653
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |iphlpapi
--- Comment #21 from Austin English austinenglish@gmail.com 2011-11-09 12:10:17 CST --- (In reply to comment #20)
Okay, thanks very much for testing in both chroot and non-chroot environments. We can safely rule that one out. If someone could change the component to iphlpapi, that would be nice. (Or, if someone could give this account of mine more privs, that'd also be nice.)
Both done.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #22 from Juan Lang juan.lang@gmail.com 2011-11-09 19:36:13 CST --- Created attachment 37422 --> http://bugs.winehq.org/attachment.cgi?id=37422 Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
How does this patch work for you?
http://bugs.winehq.org/show_bug.cgi?id=27653
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37422|0 |1 is obsolete| |
--- Comment #23 from Juan Lang juan.lang@gmail.com 2011-11-09 19:40:24 CST --- Created attachment 37423 --> http://bugs.winehq.org/attachment.cgi?id=37423 Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
Oops, last patch version depended on the trace patch. This version removes the trace in order to keep it standalone. How's this work for you?
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #24 from Hedgehog nbspjr@gmail.com 2011-11-10 02:31:25 CST --- Created attachment 37425 --> http://bugs.winehq.org/attachment.cgi?id=37425 +iphlpapi (Patch: Implement retrieving IPv4 addresses using getifaddrs, when available)
(In reply to comment #23)
Created attachment 37423 [details] Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
Oops, last patch version depended on the trace patch. This version removes the trace in order to keep it standalone. How's this work for you?
Thanks for the patch! Unfortunately, I ran into a problem: wine outputs that trace I attached and then game stucks in the middle of authentication process, eating all available CPU time. Am I doing something wrong or there is some kind of endless loop in the patch probably?
At the moment I'm going to build the lastest wine and run the game from clean prefix to see if that would help
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #25 from Hedgehog nbspjr@gmail.com 2011-11-10 03:35:58 CST --- (In reply to comment #24)
At the moment I'm going to build the lastest wine and run the game from clean prefix to see if that would help
Same thing :( Stucks at authorization process. Tried both chroot and actual system
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #26 from Juan Lang juan.lang@gmail.com 2011-11-10 09:41:40 CST --- (In reply to comment #24)
Unfortunately, I ran into a problem: wine outputs that trace I attached and then game stucks in the middle of authentication process, eating all available CPU time. Am I doing something wrong or there is some kind of endless loop in the patch probably?
Gah, of course you're right. Sorry about that! I'll send a new patch here soon.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #27 from Hedgehog nbspjr@gmail.com 2011-11-10 09:43:00 CST --- I'm not familiar with programming stuff, but... I tried to discover is there any loop causes problem and added few pintf functions:
for (; ifa; ifa = ifa->ifa_next) if (ifa->ifa_addr && ifa->ifa_addr->sa_family == AF_INET) numAddresses++; + printf("countIPv4Addresses returns %d\n", numAddresses); return numAddresses;
printf("Prior to while\n"); + while (!ret && ifPtr) { if (!ifPtr->ifa_addr || ifPtr->ifa_addr->sa_family != AF_INET) continue;
+ printf("Entered while\n");
now output looks like this: trace:iphlpapi:GetAdaptersInfo pAdapterInfo 0x0, pOutBufLen 0x33a9c0 countIPv4Addresses returns 3 trace:iphlpapi:GetAdaptersInfo returning 111 trace:iphlpapi:GetAdaptersInfo pAdapterInfo 0x7742360, pOutBufLen 0x33a9c0 countIPv4Addresses returns 3 countIPv4Addresses returns 3 Prior to while
After that it's quiet and wine not responding.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #28 from Hedgehog nbspjr@gmail.com 2011-11-10 09:44:23 CST --- (In reply to comment #26)
Gah, of course you're right. Sorry about that! I'll send a new patch here soon.
Oops, you've discovered the problem already, delete my previous comment if possible and necessary
http://bugs.winehq.org/show_bug.cgi?id=27653
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37423|0 |1 is obsolete| |
--- Comment #29 from Juan Lang juan.lang@gmail.com 2011-11-10 09:47:25 CST --- Created attachment 37429 --> http://bugs.winehq.org/attachment.cgi?id=37429 Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
Hopefully this one doesn't have an infinite loop :(
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #30 from Juan Lang juan.lang@gmail.com 2011-11-10 09:49:08 CST --- (In reply to comment #27)
Prior to while
After that it's quiet and wine not responding.
Yeah, the dumb error was that I never updated the pointer. The loop invariant was correct, but I never set ifPtr to ifPtr->ifa_next. Sheesh.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #31 from Hedgehog nbspjr@gmail.com 2011-11-10 10:26:09 CST ---
Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
Cheers! I successfully proceeded to the character creation screen! Thanks alot, it worked: http://i.imgur.com/TZuoE.png
Hopefully this one doesn't have an infinite loop :(
Really, you shouldn't worry about this. We're testing it anyway :]
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #32 from Hedgehog nbspjr@gmail.com 2011-11-11 05:11:50 CST --- Okay, I had more time today to play a bit. I was able to login, create character and play the game. Done few missions so far and everything looks fine, except that there is some graphical artifacts when a character is inside the station, but it's not related to this bug so I won't discuss it here.
Feel free to ask if you want me to do more testing.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #33 from Juan Lang juan.lang@gmail.com 2011-11-11 10:12:17 CST --- Thanks! I might ask you to test other patches in the same area, mainly because I don't have a FreeBSD box to compile on. Functionally, this one's done, and the other patches I have in mind are just tidy-ups, so I'll submit this one and get to you offline about the others when I have them.
Regarding graphical issues: I don't know if there are other bugs open for them or not. If you can't find any, you can open bugs about those too.
http://bugs.winehq.org/show_bug.cgi?id=27653
Juan Lang juan.lang@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #37429|0 |1 is obsolete| |
--- Comment #34 from Juan Lang juan.lang@gmail.com 2011-11-11 10:41:55 CST --- Created attachment 37447 --> http://bugs.winehq.org/attachment.cgi?id=37447 Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
Actually, I lied. Would you mind testing this one too? It reduces the code duplication of the previous attempt.
http://bugs.winehq.org/show_bug.cgi?id=27653
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #35 from Bruno Jesus 00cpxxx@gmail.com 2011-11-11 12:33:03 CST --- Sorry to bother but why do you check the ret var in the for if it's static? Or am I missing somehing?
+ ret = NO_ERROR; + (*ppIpAddrTable)->dwNumEntries = numAddresses; + for (ifp = ifa; !ret && ifp; ifp = ifp->ifa_next) + { + if (!ifp->ifa_addr || ifp->ifa_addr->sa_family != AF_INET) + continue; + + getIPAddrRowByName(&(*ppIpAddrTable)->table[i], + ifp->ifa_name, ifp->ifa_addr); + i++; + }
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #36 from Juan Lang juan.lang@gmail.com 2011-11-11 12:49:28 CST --- (In reply to comment #35)
Sorry to bother but why do you check the ret var in the for if it's static? Or am I missing somehing?
No, that was an oversight. Thanks for spotting it.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #37 from Juan Lang juan.lang@gmail.com 2011-11-13 10:56:53 CST --- Patch sent, not ignoring the return value Bruno pointed out in comment 35: http://www.winehq.org/pipermail/wine-patches/2011-November/108729.html
I also sent a couple of tidy-up patches to go along with this one, which are functionally no-ops.
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #38 from David Naylor naylor.b.david@gmail.com 2011-11-13 11:11:48 CST --- I can confirm this patch works (the first version of it).
I will be uploading FreeBSD packages (1.3.32) to mediafire with the first version of the patch.
Thanks to you both for fixing this...
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #39 from Hedgehog nbspjr@gmail.com 2011-11-14 06:45:03 CST --- (In reply to comment #34)
Created attachment 37447 [details] Patch: Implement retrieving IPv4 addresses using getifaddrs, when available
Actually, I lied. Would you mind testing this one too? It reduces the code duplication of the previous attempt.
Sorry, I was kinda busy this weekend. Do you still need testing for this attachment?
http://bugs.winehq.org/show_bug.cgi?id=27653
--- Comment #40 from Juan Lang juan.lang@gmail.com 2011-11-14 08:15:35 CST --- No worries :) No, it was mainly a sanity check that I hadn't broken the compile on FreeBSD, I've tested it here and it seems to work. Thanks!
http://bugs.winehq.org/show_bug.cgi?id=27653
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |25b014b6e73138db8087ee290c1 | |b9a65fa15db15 Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #41 from Juan Lang juan_lang@yahoo.com 2011-11-14 14:42:47 CST --- Should be fixed; please reopen if I screwed something up.
http://bugs.winehq.org/show_bug.cgi?id=27653
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #42 from Alexandre Julliard julliard@winehq.org 2011-11-18 13:03:40 CST --- Closing bugs fixed in 1.3.33.
-
wine-bugs＠winehq.org