http://bugs.winehq.org/show_bug.cgi?id=20041
Summary: Multiplayer not working for Rise of Nation Gold Product: Wine Version: 1.1.29 Platform: PC URL: http://www.microsoft.com/games/riseofnations/ OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: dr_kneh@hotmail.com
Created an attachment (id=23589) --> (http://bugs.winehq.org/attachment.cgi?id=23589) Console Dump
Installing and playing (including sound) works after following guide at: http://www.damonkohler.com/2008/09/how-to-run-rise-of-nations-with-wine.html
However, as soon as you choose one of the two multiplayer options in the Multiplayer Menu, a message appears saying "Unable to establish a network connection. Please check your network connection and try again."
Although my sound has stopped working after I messed something up, the game otherwise works normal, and the same thing happened when sound was working. When I click one of the options, I get the 'fixme:thread' message, followed by the two 'fixme:iphlpapi' messages concerning IPv6 support. Therefore I tried to disable IPv6 several ways and reinstall the game each time, and tried editing the /etc/modprobe.d/hosts files according to the wine FAQ, but the problem still appears.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #1 from Juan Lang juan_lang@yahoo.com 2010-06-15 17:41:29 --- What's the status with a more recent Wine (1.2rc3 or later?)
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Luis ntrrgc@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ntrrgc@gmail.com
--- Comment #2 from Juan Luis ntrrgc@gmail.com 2010-09-06 18:08:22 CDT --- Still present.. (1.3.1)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #3 from Juan Luis ntrrgc@gmail.com 2010-09-06 19:22:09 CDT --- Seems in 1.1.18 this worked... and now, it does not. See http://appdb.winehq.org/objectManager.php?sClass=version&iId=13523&i...
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #4 from Juan Luis ntrrgc@gmail.com 2010-09-06 19:44:38 CDT --- After testing lots of wine versions with the same install, seems to me like 1.1.20 is the last version to work with Rise of Nations multiplayer game.
1.1.21 and later show "Unable to establish a network connection."
Seems like a regression in 1.1.21, perpetuated until today, perhaps in DirectPlay, perpetuated until today.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #5 from Juan Luis ntrrgc@gmail.com 2010-09-08 12:03:46 CDT --- After making a regression test, I discovered the problematic patch:
commit f0491f61ba04d62ba1e6c7d596e14610446a1bdc Author: Hans Leidekker hans@codeweavers.com Date: Wed Apr 29 11:41:02 2009 +0200
iphlpapi: Implement GetAdaptersAddresses.
However, that regression comes from wine-1.1.20, while we are in wine-1.3.2, and reverting iphlpapi to wine-1.1.20 one into the latest build, does not work. For some reason, it fails to detect network on Rise of Nations.
Anyway, better than reverting we should fix iphlpapi to made it work with Rise of Nations.
http://bugs.winehq.org/show_bug.cgi?id=20041
Christian Widmer shadow@umbrox.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hans@meelstraat.net
http://bugs.winehq.org/show_bug.cgi?id=20041
Christian Widmer shadow@umbrox.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shadow@umbrox.de
--- Comment #6 from Christian Widmer shadow@umbrox.de 2010-09-08 22:32:54 CDT --- After having done a bisect myself, I found the same commit to be responsible for Dungeon Siege multiplayer not working. I also added the author of the patch to CC as suggested by the regression testing article on the wine wiki.
http://bugs.winehq.org/show_bug.cgi?id=20041
Christian Widmer shadow@umbrox.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #7 from Christian Widmer shadow@umbrox.de 2010-09-08 22:36:33 CDT --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #8 from Hans Leidekker hans@meelstraat.net 2010-09-09 02:15:47 CDT --- So does it work if you revert that commit?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #9 from Juan Luis ntrrgc@gmail.com 2010-09-09 07:34:56 CDT --- Yes, it works in wine-1.1.21; but reverting it in the present wine-1.3.2, is quite more difficult. Also, iphlpapi has received some improvements since 1.1.20, and does not make sense to remove them. We should find why it fails, and repair it.
(In reply to comment #8)
So does it work if you revert that commit?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #10 from Christian Widmer shadow@umbrox.de 2010-09-09 10:01:30 CDT --- What is also quite strange is that - at least for Dungeon Siege - someone wrote a test for wine 1.1.37 running on Debian Squeeze where he claims the multiplayer to work. Therefore I tested this wine version but it did not work for me on Ubuntu 10.04 (64-bit). Further testing then brought me to the same result as Jean. It is maybe also worth noting that both games use Direct Play.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #11 from Christian Widmer shadow@umbrox.de 2010-09-09 10:06:42 CDT --- Of course I meant Juan. Sorry for spelling your name wrong.
(In reply to comment #10)
What is also quite strange is that - at least for Dungeon Siege - someone wrote a test for wine 1.1.37 running on Debian Squeeze where he claims the multiplayer to work. Therefore I tested this wine version but it did not work for me on Ubuntu 10.04 (64-bit). Further testing then brought me to the same result as Jean. It is maybe also worth noting that both games use Direct Play.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #12 from Juan Luis ntrrgc@gmail.com 2010-09-09 10:16:50 CDT --- (In reply to comment #10)
What is also quite strange is that - at least for Dungeon Siege - someone wrote a test for wine 1.1.37 running on Debian Squeeze where he claims the multiplayer to work. Therefore I tested this wine version but it did not work for me on Ubuntu 10.04 (64-bit). Further testing then brought me to the same result as Jean. It is maybe also worth noting that both games use Direct Play.
Problem seems to reside before on iphlpapi.dll, not in Direct Play.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #13 from Juan Lang juan_lang@yahoo.com 2010-09-09 12:09:14 CDT --- Hm, no iphlpapi application. Please attach a +iphlpapi log.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #14 from Juan Lang juan_lang@yahoo.com 2010-09-09 12:09:47 CDT --- (In reply to comment #13) s/application/component/
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #15 from Christian Widmer shadow@umbrox.de 2010-09-09 12:26:25 CDT --- Created an attachment (id=30653) --> (http://bugs.winehq.org/attachment.cgi?id=30653) +iphlpapi log (Dungeon Siege)
Attached a +iphlpapi log as requested by comment #13.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #16 from Juan Luis ntrrgc@gmail.com 2010-09-09 13:06:18 CDT --- Created an attachment (id=30655) --> (http://bugs.winehq.org/attachment.cgi?id=30655) The iphlpapi log from wine-1.1.20 (good)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #17 from Juan Luis ntrrgc@gmail.com 2010-09-09 13:06:55 CDT --- Created an attachment (id=30656) --> (http://bugs.winehq.org/attachment.cgi?id=30656) The iphlpapi log from wine-1.1.21 (bad)
http://bugs.winehq.org/show_bug.cgi?id=20041
Christian Widmer shadow@umbrox.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30653|+iphlpapi log (Dungeon |+iphlpapi log from wine description|Siege) |1.3.2 (Dungeon Siege) (bad)
--- Comment #18 from Christian Widmer shadow@umbrox.de 2010-09-09 13:09:51 CDT --- (From update of attachment 30653) Added the wine version used to the attachment's description.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #19 from Juan Luis ntrrgc@gmail.com 2010-09-09 13:11:15 CDT --- I have uploaded two logs too. Looks that in the good version, it does not speak about num adapters, while bad version enum them and does not work anymore. :S Also, in the bad version there are some fixmes about IPv6 that aren't shown in recent versions of wine.
http://bugs.winehq.org/show_bug.cgi?id=20041
Leoanrdo José consoni_2519@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |consoni_2519@hotmail.com
--- Comment #20 from Leoanrdo José consoni_2519@hotmail.com 2010-09-12 11:19:22 CDT --- It's OK to try replacing iphlpapi.dll with a windows native version ?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #21 from Juan Luis ntrrgc@gmail.com 2010-09-13 06:41:17 CDT --- (In reply to comment #20)
It's OK to try replacing iphlpapi.dll with a windows native version ?
It does not work. I tried.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #22 from Juan Lang juan_lang@yahoo.com 2010-09-13 11:33:28 CDT --- Created an attachment (id=30730) --> (http://bugs.winehq.org/attachment.cgi?id=30730) Patch: Trace enumerated addresses
Please attach a +iphlpapi,+winsock log with this patch applied. This patch adds more debugging info, but doesn't have any functional impact. I'd like to see what the program is doing with the results of GetAdaptersAddresses.
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juan_lang@yahoo.com
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #23 from Juan Lang juan_lang@yahoo.com 2010-09-13 14:22:21 CDT --- (In reply to comment #22)
Please attach a +iphlpapi,+winsock log with this patch applied.
Oh, and could whoever posts this log also attach a +iphlpapi,+winsock log without the patch applied on Wine 1.1.20, i.e. a working Wine?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #24 from Christian Widmer shadow@umbrox.de 2010-09-13 18:37:33 CDT --- Created an attachment (id=30740) --> (http://bugs.winehq.org/attachment.cgi?id=30740) +iphlpapi,+winsock log from patched wine-git (Dungeon Siege) (bad)
Added the requested +iphlpapi,+winsock log from a patched wine-git.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #25 from Christian Widmer shadow@umbrox.de 2010-09-13 18:39:35 CDT --- Created an attachment (id=30741) --> (http://bugs.winehq.org/attachment.cgi?id=30741) +iphlpapi,+winsock log from wine-1.1.20 (Dungeon Siege) (good)
And here is the log from the working wine-1.1.20.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #26 from Juan Lang juan_lang@yahoo.com 2010-09-14 14:04:42 CDT --- In the bad log, the adapters appear to be returned successfully, and sockets are created: trace:winsock:WS_socket af=2 type=2 protocol=0 trace:winsock:WSASocketA af=2 type=2 protocol=0 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW af=2 type=2 protocol=0 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW created 0174
But no operations are done on the created sockets.
In the good log, in contrast, sockets are created and bound to a local address: trace:winsock:WS_socket af=2 type=2 protocol=17 trace:winsock:WSASocketA af=2 type=2 protocol=17 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW af=2 type=2 protocol=17 protocol_info=(nil) group=0 flags=0x1 trace:winsock:WSASocketW created 0190 trace:winsock:WS_bind socket 0190, ptr 0x82be70c { family 2, address 192.168.2.12, port 58812 }, length 16
Apparently, the information returned by GetAdaptersAddresses is insufficient to make the app happy. There's a lot that GetAdaptersAddresses doesn't return yet, so we'll have to speculate which one will do the trick. I'll attach an easy patch first.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #27 from Juan Lang juan_lang@yahoo.com 2010-09-14 14:05:28 CDT --- Created an attachment (id=30755) --> (http://bugs.winehq.org/attachment.cgi?id=30755) Patch: Set flags for adapters returned by GetAdaptersAddresses
Does this patch make any difference?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #28 from Christian Widmer shadow@umbrox.de 2010-09-14 17:36:58 CDT --- Created an attachment (id=30760) --> (http://bugs.winehq.org/attachment.cgi?id=30760) +iphlpapi,+winsock log from wine-git patched with 30755 (Dungeon Siege) (bad)
Although it does not make the multiplayer work, some of the traces disappeared from the logs.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #29 from Juan Lang juan_lang@yahoo.com 2010-09-14 21:58:11 CDT --- Okay. While this is a longer shot, could you see whether attachment 27014 has an effect?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #30 from Christian Widmer shadow@umbrox.de 2010-09-14 23:33:00 CDT --- (In reply to comment #29)
Okay. While this is a longer shot, could you see whether attachment 27014 [details] has an effect?
It has no effect concerning the game. Do you need logs again?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #31 from Juan Lang juan_lang@yahoo.com 2010-09-15 09:33:34 CDT --- No, not this time.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #32 from Christian Widmer shadow@umbrox.de 2010-09-15 13:03:30 CDT --- (In reply to comment #28)
Created an attachment (id=30760)
--> (http://bugs.winehq.org/attachment.cgi?id=30760) [details]
+iphlpapi,+winsock log from wine-git patched with 30755 (Dungeon Siege) (bad)
Although it does not make the multiplayer work, some of the traces disappeared from the logs.
I have to correct myself in this regard. The disappearing traces do not seem to be caused by the applied patch. It more looks like if they always appear the first time the application is started with a newly compiled wine. However, they vanish for subsequent runs.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #33 from Juan Lang juan_lang@yahoo.com 2010-09-16 12:18:36 CDT --- Okay. I have a patch series to add. Please apply it with the "Trace enumerated addresses" patch (attachment 30730). I don't think the "Set flags for adapters" patch (attachment 30755) is required, but it's in my tree, so if you get apply failures, you might apply it too. I'll attach 4 patches in a sec.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #34 from Juan Lang juan_lang@yahoo.com 2010-09-16 12:19:06 CDT --- Created an attachment (id=30800) --> (http://bugs.winehq.org/attachment.cgi?id=30800) Patch 1/4: Add ifdef.h
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #35 from Juan Lang juan_lang@yahoo.com 2010-09-16 12:19:32 CDT --- Created an attachment (id=30801) --> (http://bugs.winehq.org/attachment.cgi?id=30801) Patch 2/4: Move IF_OPER_STATUS to ifdef.h
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #36 from Juan Lang juan_lang@yahoo.com 2010-09-16 12:19:57 CDT --- Created an attachment (id=30802) --> (http://bugs.winehq.org/attachment.cgi?id=30802) Patch 3/4: Add Vista fields to IP_ADAPTER_ADDRESSES
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #37 from Juan Lang juan_lang@yahoo.com 2010-09-16 12:20:42 CDT --- Created an attachment (id=30803) --> (http://bugs.winehq.org/attachment.cgi?id=30803) Patch 4/4: Set gateway addresses in GetAdaptersAddresses
Please report whether this patch series improves things at all.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #38 from Christian Widmer shadow@umbrox.de 2010-09-16 12:33:53 CDT --- (In reply to comment #37)
Created an attachment (id=30803)
--> (http://bugs.winehq.org/attachment.cgi?id=30803) [details]
Patch 4/4: Set gateway addresses in GetAdaptersAddresses
Please report whether this patch series improves things at all.
Unfortunately it does not improve things.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #39 from Juan Lang juan_lang@yahoo.com 2010-09-16 12:45:53 CDT --- Created an attachment (id=30804) --> (http://bugs.winehq.org/attachment.cgi?id=30804) Patch: Set ConnectionType in GetAdaptersAddresses
Okay, one more. Like I said before, we can only speculate what the app expects (or someone with mad debugging skills can figure it out.) Does this help at all?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #40 from Christian Widmer shadow@umbrox.de 2010-09-16 16:51:27 CDT --- (In reply to comment #39)
Created an attachment (id=30804)
--> (http://bugs.winehq.org/attachment.cgi?id=30804) [details]
Patch: Set ConnectionType in GetAdaptersAddresses
Okay, one more. Like I said before, we can only speculate what the app expects (or someone with mad debugging skills can figure it out.) Does this help at all?
It does not, at least for Dungeon Siege. However, I cannot tell for Rise of Nations, although I think they are both expecting similar things.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #41 from Juan Lang juan_lang@yahoo.com 2010-09-16 18:37:06 CDT --- At this point, I'm at a loss. If there's someone with access to a Windows machine whose copy of either game works and can compile a Windows .exe, could you compile the following C program: http://www.ipv6style.jp/files/ipv6/en/apps/20060320_2/GetAdaptersAddresses-E...
and email the result to me? I'd like to compare the things the Windows outputs with the things that our GetAdaptersAddresses does, to try to guess what else the game is expecting to see.
Another thing I'd be curious to see is a +iphlpapi,+seh,+relay log, in case there's some exception that's at the root of the problem, but that's caught by the game.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #42 from Christian Widmer shadow@umbrox.de 2010-09-16 19:31:00 CDT --- (In reply to comment #41)
At this point, I'm at a loss. If there's someone with access to a Windows machine whose copy of either game works and can compile a Windows .exe, could you compile the following C program: http://www.ipv6style.jp/files/ipv6/en/apps/20060320_2/GetAdaptersAddresses-E...
and email the result to me? I'd like to compare the things the Windows outputs with the things that our GetAdaptersAddresses does, to try to guess what else the game is expecting to see.
Another thing I'd be curious to see is a +iphlpapi,+seh,+relay log, in case there's some exception that's at the root of the problem, but that's caught by the game.
I tried to provide you with the log but it grew bigger than 700MB before the program even fully loaded. Concerning the windows stuff: even though I never compiled on a windows system, I am going to give it a try this weekend.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #43 from Juan Lang juan_lang@yahoo.com 2010-09-16 19:38:28 CDT --- (In reply to comment #42)
I tried to provide you with the log but it grew bigger than 700MB before the program even fully loaded. Concerning the windows stuff: even though I never compiled on a windows system, I am going to give it a try this weekend.
Okay. A +iphlpapi,+seh log is probably enough too.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #44 from Christian Widmer shadow@umbrox.de 2010-09-16 20:00:33 CDT --- (In reply to comment #43)
(In reply to comment #42)
I tried to provide you with the log but it grew bigger than 700MB before the program even fully loaded. Concerning the windows stuff: even though I never compiled on a windows system, I am going to give it a try this weekend.
Okay. A +iphlpapi,+seh log is probably enough too.
There it is: http://umbrox.de/public/winelogIphplSeh.log (2.5MB)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #45 from Juan Lang juan_lang@yahoo.com 2010-09-16 20:06:06 CDT --- Thanks! Here's what I was looking for, I think:
trace:iphlpapi:GetAdaptersAddresses num adapters 2 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6397e9 ip=006397e9 tid=0009 trace:seh:raise_exception info[0]=00000000 trace:seh:raise_exception info[1]=06dde000 trace:seh:raise_exception eax=00002800 ebx=04fc1374 ecx=00000a00 edx=000006e4 esi=06dde000 edi=05d5ab08 trace:seh:raise_exception ebp=0032f874 esp=0032f850 cs=0023 ds=002b es=002b fs=0063 gs=006b flags=00010206 trace:seh:call_vectored_handlers calling handler at 0x7e71c870 code=c0000005 flags=0 trace:seh:call_vectored_handlers handler at 0x7e71c870 returned 0 trace:seh:call_stack_handlers calling handler at 0x409f80 code=c0000005 flags=0 trace:seh:call_stack_handlers handler at 0x409f80 returned 0
As a guess, it could be that the application expects some member of IP_ADAPTERS_ADDRESSES to be set that currently isn't. For example, the program I asked you to try to compile expects the adapter's FriendlyName, Description, and DnsSuffix not to be empty, whereas in Wine they are. I can't guarantee a quick patch, but at least that gives us more things to try.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #46 from Wylda wylda@volny.cz 2010-09-18 19:35:27 CDT --- Created an attachment (id=30855) --> (http://bugs.winehq.org/attachment.cgi?id=30855) output of example from comment #41
(In reply to comment #41)
you compile the following C program and email the result to me?
Hi Juan, attaching just in case you are still waiting for that.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #47 from Juan Lang juan_lang@yahoo.com 2010-09-20 11:49:04 CDT --- Created an attachment (id=30888) --> (http://bugs.winehq.org/attachment.cgi?id=30888) Set adapter description in GetAdaptersAddresses
Does this help?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #48 from Christian Widmer shadow@umbrox.de 2010-09-20 16:14:09 CDT --- (In reply to comment #47)
Created an attachment (id=30888)
--> (http://bugs.winehq.org/attachment.cgi?id=30888) [details]
Set adapter description in GetAdaptersAddresses
Does this help?
No, it does not.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #49 from Leonardo José consoni_2519@hotmail.com 2010-09-21 07:14:03 CDT --- in the Wine 1.1.21 changelog there are 3 references to iphlpapi:
iphlpapi: GetAdaptersAddresses required for some utility classes in system.net namespace (.NET)
Hans Leidekker (12):
iphlpapi: Implement GetAdaptersAddresses. iphlpapi: Add tests for GetAdaptersAddresses.
is this of some use ?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #50 from Hans Leidekker hans@meelstraat.net 2010-09-21 08:19:56 CDT --- Try commenting out GetAdaptersAddresses in the spec file, to rule out a regression elsewhere. Or the combination of Juan's patches.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #51 from Juan Lang juan_lang@yahoo.com 2010-09-21 11:01:16 CDT --- (In reply to comment #48)
No, it does not.
Out of curiosity, have you tried all the patches I suggested together? Assuming you have, do you still see access violations (status code 0xc0000005) in a +iphlpapi,+seh log shortly after a GetAdaptersAddresses call?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #52 from Hans Leidekker hans@meelstraat.net 2010-09-21 11:10:37 CDT --- You might want to add +relay,+tid to see if anything interesting happens between the call to GetAdaptersAddresses and the exception.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #53 from Christian Widmer shadow@umbrox.de 2010-09-21 11:46:59 CDT --- Created an attachment (id=30899) --> (http://bugs.winehq.org/attachment.cgi?id=30899) +iphlpapi,+seh,+relay,+tid log extract from patched wine-git (Dungeon Siege) (bad)
Both of your questions can be answered with yes, Juan. I have also attached a log extract as suggested by Hans. It shows what is going on between the call and the exception.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #54 from Juan Lang juan_lang@yahoo.com 2010-09-23 17:49:52 CDT --- I've sent in most of these patches, just so syncing won't be such a challenge. I confess I can't guess what the problem is from looking at the +iphlpapi,+seh,+relay,+tid log in attachment 30899.
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30730|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30755|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30800|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30801|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30802|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30803|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30888|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #30804|0 |1 is obsolete| |
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #55 from Juan Lang juan_lang@yahoo.com 2010-09-24 16:35:14 CDT --- The patches I attached to this bug have been committed. Please attach a +iphlpapi,+seh,+relay,+tid log again. Please include everything from the first trace:iphlpapi:GetAdaptersAddresses line to the first access violation.
I know nothing will have changed, but I'm curious whether the memory being read from is anywhere near the input buffer to GetAdaptersAddresses, which I can't tell from the last log you attached.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #56 from Christian Widmer shadow@umbrox.de 2010-10-11 08:37:55 CDT --- Sorry for the long delay. I completely forgot about your request for a log. Here it is: http://umbrox.de/public/winelogIphlSehRelay.log (5.5MB)
The log is taken from the current git version of wine. I hope it helps.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #57 from Dmitry Timoshkov dmitry@codeweavers.com 2010-10-11 09:32:45 CDT --- (In reply to comment #56)
Sorry for the long delay. I completely forgot about your request for a log. Here it is: http://umbrox.de/public/winelogIphlSehRelay.log (5.5MB)
The log is taken from the current git version of wine. I hope it helps.
Please compress it with 'bzip2 -9' and attach it here.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #58 from Christian Widmer shadow@umbrox.de 2010-10-11 09:42:56 CDT --- Created an attachment (id=31221) --> (http://bugs.winehq.org/attachment.cgi?id=31221) +iphlpapi,+seh,+relay,+tid log extract (compressed) from patched wine-git (Dungeon Siege) (bad)
Here you go!
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #59 from Juan Lang juan_lang@yahoo.com 2010-10-11 10:13:14 CDT --- (In reply to comment #56)
Sorry for the long delay. I completely forgot about your request for a log. Here it is:
Not very helpful to me, unfortunately. Here's the bit I was interested in: 0009:Call iphlpapi.GetAdaptersAddresses(00000000,0000000e,00000000,04e5f240,0032f854) ret=01383f62 (snip) 001f:trace:seh:raise_exception code=c0000005 flags=0 addr=0x6397e9 ip=006397e9 tid=001f 001f:trace:seh:raise_exception info[0]=00000000 001f:trace:seh:raise_exception info[1]=06de3000
That is, the crash happens with an access to a NULL pointer on thread 1f, while the GetAdaptersAddresses calls are happening on thread 9. That doesn't give us much to go on, and by now GetAdaptersAddresses isn't returning empty info for many things.
I just noticed something minor I hadn't before: 0009:trace:iphlpapi:GetAdaptersAddresses (0, 0000000e, (nil), (nil), 0x32f678)
The flags are GAA_FLAG_SKIP_ANYCAST | GAA_FLAG_SKIP_MULTICAST | GAA_FLAG_SKIP_DNS_SERVER. Since we don't return anycast, multicast or DNS server addresses anyway, we aren't doing any harm by ignoring the flags so far.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #60 from Juan Lang juan_lang@yahoo.com 2010-10-11 10:32:53 CDT --- (In reply to comment #59)
I just noticed something minor I hadn't before: 0009:trace:iphlpapi:GetAdaptersAddresses (0, 0000000e, (nil), (nil), 0x32f678)
The flags are GAA_FLAG_SKIP_ANYCAST | GAA_FLAG_SKIP_MULTICAST | GAA_FLAG_SKIP_DNS_SERVER. Since we don't return anycast, multicast or DNS server addresses anyway, we aren't doing any harm by ignoring the flags so far.
As usual, I may be speaking too soon. GAA_FLAG_INCLUDE_ALL_GATEWAYS isn't specified, so perhaps I shouldn't be returning gateway addresses. On the other hand, gateways weren't included in the initial implementation of GetAdaptersAddresses, so that probably isn't the cause of the regression.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #61 from Juan Lang juan_lang@yahoo.com 2010-10-11 13:07:01 CDT --- I sent some patches to handle flags more correctly. I don't suspect they'll help, but at least they'll eliminate that line of speculation. I have one more hunch, that the app might be using the DNS suffix returned by GetAdaptersAddresses. I'll attach a patch against current git in a sec. (It won't apply on top of the patches I just sent, I'll rebase and resend once my patches get accepted.)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #62 from Juan Lang juan_lang@yahoo.com 2010-10-11 13:07:45 CDT --- Created an attachment (id=31222) --> (http://bugs.winehq.org/attachment.cgi?id=31222) Patch: Return DNS suffix for all non-loopback adapters
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #63 from Christian Widmer shadow@umbrox.de 2010-10-11 15:30:39 CDT --- (In reply to comment #62)
Created an attachment (id=31222)
--> (http://bugs.winehq.org/attachment.cgi?id=31222) [details]
Patch: Return DNS suffix for all non-loopback adapters
Does this patch help?
No, it does not.
http://bugs.winehq.org/show_bug.cgi?id=20041
Keldon Jones keldon@keldon.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |keldon@keldon.net
http://bugs.winehq.org/show_bug.cgi?id=20041
Richard shiningarcanine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |shiningarcanine@gmail.com
--- Comment #64 from Richard shiningarcanine@gmail.com 2010-10-28 22:13:52 CDT --- (In reply to comment #63)
(In reply to comment #62)
Created an attachment (id=31222)
--> (http://bugs.winehq.org/attachment.cgi?id=31222) [details] [details]
Patch: Return DNS suffix for all non-loopback adapters
Does this patch help?
No, it does not.
Christan, could you produce a new trace with the patches installed? There is a possibility that a chain of dependencies are broken, which is keeping things from working. Some of the patches might have fixed certain issues, which would reveal the next link in the chain.
http://bugs.winehq.org/show_bug.cgi?id=20041
Christian Widmer shadow@umbrox.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #31221|0 |1 is obsolete| |
--- Comment #65 from Christian Widmer shadow@umbrox.de 2010-10-30 18:06:45 CDT --- Created an attachment (id=31616) --> (http://bugs.winehq.org/attachment.cgi?id=31616) +iphlpapi,+seh,+relay,+tid log extract (compressed) from patched wine-git (Dungeon Siege) (bad)
Here is a log produced by yesterday's wine-git which I think has all the patches.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #66 from Richard shiningarcanine@gmail.com 2010-11-25 09:58:17 CST --- Rise of Nations can update itself inside of WINE without any assistance, which demonstrates that internet connectivity works. There is a discussion on an internet forum about getting the OnLive Gaming Service client to work with WINE and someone said:
"OnLive checks for a Windows Ethernet driver & connection before running. The problem is that OnLive can't detect these non-windows network devices."
http://onlivefans.com/showthread.php?4025-LINUX-Getting-Onlive-to-run-in-Lin...
After reading that, I strongly suspect that Rise of Nations' multiplayer functionality checks the state of the network adapter before doing anything else. Since WINE likely has a stub that says that there is no network adapter, we then see the error message:
"Unable to establish a network connection. Please check your network connection and try again."
This happens even when you attempt to host a game, so I doubt that the failure occurs because of network connectivity. I also know for a fact that the game can talk over the network because it can talk to Microsoft's update servers, so this definitely is not a problem with network connectivity. With those things in mind, I think that the failure is related to hardware detection. I think patching that area of WINE could get Rise of Nations' multiplayer functionality to work.
I also did some more digging and a hint regarding the cause of the error message is available at Microsoft's knowledge database, which suggests that "The Microsoft DirectPlay Dpnet.dll file is incorrectly installed or registered.":
http://support.microsoft.com/kb/829151
Perhaps Rise of Nations is querying the network state through Dpnet.dll, which then makes some system calls which WINE has implemented in stubs. Those stubs of course have no real implementation behind them so after talking with them, Dpnet.dll thinks that there is no network adapter present and reports that to Rise of Nations.
http://bugs.winehq.org/show_bug.cgi?id=20041
Pilot pilota51@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pilota51@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20041
Chris cbaines8@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cbaines8@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #67 from Chris cbaines8@gmail.com 2011-10-12 07:27:59 CDT --- Any progress with this, I just built wine from git, but still no multiplayer.
http://bugs.winehq.org/show_bug.cgi?id=20041
Louis Lenders xerox_xerox2000@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |xerox_xerox2000@yahoo.co.uk
--- Comment #68 from Louis Lenders xerox_xerox2000@yahoo.co.uk 2011-10-12 12:42:08 CDT --- (In reply to comment #67)
Any progress with this, I just built wine from git, but still no multiplayer.
Could you attach terminal output please?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #69 from Chris cbaines8@gmail.com 2011-10-12 15:44:28 CDT --- Created attachment 36864 --> http://bugs.winehq.org/attachment.cgi?id=36864 Log from rise of nations trying to enter the "Local Area Network "... screen
The last three lines came up when I tried to enter the screen.
http://bugs.winehq.org/show_bug.cgi?id=20041
Fleck Fleck@Rullz.lv changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Fleck@Rullz.lv
--- Comment #70 from Fleck Fleck@Rullz.lv 2011-12-28 18:21:16 CST --- So, any ideas how to fix multiplayer? When i have directx9 installed - i get error when i press LAN or Direct Internet button: Unable to establish a network connection. Please check your network connection and try again. When i use built in dpnet in winecfg - i can go inside LAN or Direct Internet, but when i press Create button - i get another error: Unable to establish a session. Seems that i cannot join a game too... will try that later in LAN!
Any ideas?
http://bugs.winehq.org/show_bug.cgi?id=20041
Lauri Niskanen ape@ape3000.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ape@ape3000.com
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #71 from Starous starous@volny.cz 2012-10-24 16:05:02 CDT --- Created attachment 42252 --> http://bugs.winehq.org/attachment.cgi?id=42252 RC Cars winsock log
Hello,
unfortunately I have no ideas (according to comment #70) but I find maybe the same or similar bug in game RC Cars (older version of Smash Cars created by CREAT Studio).
I installed this game under Wine some time ago and it worked fine - except multiplayer modes.
Today I tried this game in multiplayer mode again after installing newest winsock patch from this - http://bugs.winehq.org/show_bug.cgi?id=31994 - but without success. So, I tried to do some simple debug and I found this game is using direct play dpnet.dll.
OK, I tried to find something related to this in Wine Bugzilla - and I found http://wiki.winehq.org/DirectPlayGames It looked greatly, so I installed native direct play according to this "manual" - but nothing happened.
I searched in Wine Bugzilla again and I found this bug (i.e. 20041) - it looks very similarly (for me) - in RC Cars winsock log are some records showing creating of some sockets which are closed without using them.
Is there some progress? I could do some small help e.g. in testing of new ideas on the RC Cars game. (But not so fast as I did yesterday when I was helping in solving of bug 31994 :-( )
I am thinking to try patches included in this bug - but they seems to be related to some old Wine version(s), so I am afraid they are not usable - or?
BR
http://bugs.winehq.org/show_bug.cgi?id=20041
Starous starous@volny.cz changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |starous@volny.cz
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #72 from Starous starous@volny.cz 2012-10-26 10:56:09 CDT --- Created attachment 42261 --> http://bugs.winehq.org/attachment.cgi?id=42261 RC Cars -all,+winsock,+iphlpapi,+seh
Hi, I added new log with another debug settings. Log monitors five attempts to refresh network game servers list.
What is interesting for me:
1. It looks like it could be the same problem as there is no another game action after calling of GetAdaptersAddresses. (But there is no exception after calling GetAdaptersAddresses.)
2. But it may be also another problem - maybe related to IPv6 - ? According to logs - only the socket of af=23 (i.e. IPv6) is created and no another when game tries to join network multiplayer. But I expect the game is not supporting IPv6, at least according to network multiplayer menu items (there is only IPv4 address field, no IPv6).
http://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #73 from Bruno Jesus 00cpxxx@gmail.com 2012-10-26 11:54:42 CDT --- Can you reproduce the issue with the trial version from http://www.microsoft.com/games/riseofnations/downloads.aspx ?
It's weird that the game creates the socket and closes it without doing anything, try a +relay,+tid and check what it's doing from the socket creation until the closure. Add a trace in WS_getsockopt, case WS_SO_RCVBUF to print the value that is being returned in optval (it should be a %d, needs cast) because relay will only get the function return, this is after line 2622.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #74 from Starous starous@volny.cz 2012-10-26 15:12:41 CDT --- (In reply to comment #73)
Can you reproduce the issue with the trial version from http://www.microsoft.com/games/riseofnations/downloads.aspx ?
Hi, I cannot download this game, it looks like it is not currently available, there is result of download button click:
Server Error 404 - File or directory not found. The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #75 from Starous starous@volny.cz 2012-10-26 16:34:03 CDT --- Created attachment 42265 --> http://bugs.winehq.org/attachment.cgi?id=42265 Change in socket.c and (strange) examples from log
Hi,
I tried to add new tracing as You suggested. But something is probably going wrong (maybe I put TRACE on wrong place?) - see attachment. It looks like some trace texts are not complete or missing. (?)
(Complete log had about 500MB)
So, I tried little bit another change in socket.c - I moved TRACE on another place (before calling of release_sock_fd()) and tried to run game again. The result of this second try looks (very) different - at least for the first look from my point of view. I will try to put complete bzip2-ed log here as next attachment (it has about 7MB and more than 600MB when uncompressed...).
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #76 from Starous starous@volny.cz 2012-10-26 16:45:35 CDT --- Created attachment 42266 --> http://bugs.winehq.org/attachment.cgi?id=42266 Link to RCCars complete log with -all,+winsock,+iphlpapi,+seh,+relay,+tid
There is promised complete log. Unfortunately, it is not possible to sent file bigger than 1MB, so inside attachment You find the link to log stored elsewhere (I hope it will work).
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #77 from Starous starous@volny.cz 2012-10-26 17:37:18 CDT --- One, probably bad idea:
As I see the log, there are some accesses into Windows registry: HKLM/Software/DirectPlay HKLM/Software/DirectPlay8
Some keys or values appeared differently in Wine and Windows.
So I tried to import these two branches from Windows into Wine, because I had idea - there could be some important keys/values needed for proper function of DirectPlay in registry.
But it does not help, it looks to be bad idea.
Maybe one more thing: Inside key "Internet TCP/IP Connection For DirectPlay" exists REG_SZ value NATHelp="dpnhupnp.dll". This DLL does not exists in Wine - could it be a problem?
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #78 from Starous starous@volny.cz 2012-10-27 09:54:09 CDT --- One more interesting/strange thing:
Logs of running game are different if I change and recompile winsock (or maybe also something else - I didn't try it) and re-install Wine (by "make install"):
Log of the first run of the game (Wine) contains some additional calling of winsock function like ioctlsocket, htons, htonl, bind, getsockname etc.
Log of the second (and any next) run contains ONLY calling of socket, closesocket and sometimes getsockopt.
WHY??? Any idea?
In both cases the network multiplayer does not work.
(If You want, I can send there both full logs (1st and 2nd run) - both have approx. 500MB uncompressed. But, unfortunately, I don't have enough space on my web page. Do You have some storage place for long logs?)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #79 from Fleck Fleck@Rullz.lv 2012-10-27 16:21:18 CDT --- I can host your log files if needed!
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #80 from Starous starous@volny.cz 2012-10-28 05:23:11 CDT --- (In reply to comment #78)
One more interesting/strange thing:
Logs of running game are different if I change and recompile winsock (or maybe also something else - I didn't try it) and re-install Wine (by "make install"):
Log of the first run of the game (Wine) contains some additional calling of winsock function like ioctlsocket, htons, htonl, bind, getsockname etc.
Log of the second (and any next) run contains ONLY calling of socket, closesocket and sometimes getsockopt.
WHY??? Any idea?
It is maybe false "alarm". The additional winsock calling are at the beginning of the log, before loading of DPNET.DLL - so, it looks like these calling are probably related to some initialization of Wine itself instead of game.
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #81 from Starous starous@volny.cz 2012-10-28 05:26:21 CDT --- (In reply to comment #79)
I can host your log files if needed!
Could You send to me some instructions how/where load the logs? Of course, if somebody will want to analyze them... :-)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #82 from Starous starous@volny.cz 2012-10-28 05:49:32 CDT --- (In reply to comment #73)
It's weird that the game creates the socket and closes it without doing anything, try a +relay,+tid and check what it's doing from the socket creation until the closure. Add a trace in WS_getsockopt, case WS_SO_RCVBUF to print the value that is being returned in optval (it should be a %d, needs cast) because relay will only get the function return, this is after line 2622.
I have some ideas, maybe wrong/stupid:
1. GetAdaptersAddresses: It (maybe) looks like the game stops preparing of network multiplayer immediately after calling of GetAdaptersAddresses.
AFAIK, all the games are little bit older, so maybe they expect some exact (or maximal) size of IP_ADAPTER_ADDRESSES structure. As I saw on MS page http://msdn.microsoft.com/en-us/library/windows/desktop/aa366058%28v=vs.85%2..., there are different sizes of IP_ADAPTER_ADDRESSES structure depending of Windows version. And, if I understand source code properly, Wine returns always the same structure, independent of windows version slected in WineCfg.
Additionally, I didn't see the last member (PIP_ADAPTER_DNS_SUFFIX FirstDnsSuffix; - according to link above) in IP_ADAPTER_ADDRESSES structure in iptypes.h.
2. Again GetAdaptersAddresses: There is one more interesting thing on this page: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365915%28v=vs.85%2... See the Remarks about size of IP_ADAPTER_ADDRESSES linked structures - how to determine needed memory size via two subsequent calling of GetAdaptersAddresses. Even if it is discouraged, it looks like DPNET.DLL or the game itself is doing exactly this thing - according to my logs, the first call of GetAdaptersAddresses has parameter AdapterAddresses=NULL.
Maybe there is some similar situation about calling of socket/getsockopt/closesocket?
http://bugs.winehq.org/show_bug.cgi?id=20041
Fenriswolf fenriswolf13@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fenriswolf13@gmx.de
--- Comment #83 from Fenriswolf fenriswolf13@gmx.de 2013-03-03 06:36:21 CST --- are there some new results? i want to play it with some friends, w/o using windows
http://bugs.winehq.org/show_bug.cgi?id=20041
Hugo hpessotti@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hpessotti@gmail.com
--- Comment #84 from Hugo hpessotti@gmail.com 2013-08-03 21:19:45 CDT --- Any progress on this issue? Wine 1.7 still not working
http://bugs.winehq.org/show_bug.cgi?id=20041
Solerman Kaplon solerman.kaplon@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |solerman.kaplon@gmail.com
--- Comment #85 from Solerman Kaplon solerman.kaplon@gmail.com --- I think the info here about the /etc/hosts is relevant: http://appdb.winehq.org/objectManager.php?sClass=version&iId=9180&iT...
The game itself warns about having more than one address, it seems to bind to the first one, if it isn't the correct one it will not work. In linux, maybe the 127.* is the first one, which isn't going to work. Windows doesn't have that kind of address, so the first one should always be the first on a real adapter (eth* or wlan* kind of devices)
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #86 from Solerman Kaplon solerman.kaplon@gmail.com --- Also, on my machine, ipconfig also lists inactive adapters (eg: eth0 without a connected cable).
http://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #87 from Fleck Fleck@Rullz.lv --- No true! Windows has loopback device, it's just hidden and not visible by default, like many other things in Windows! You can even set up Windows to show loopback device in Network Connections as adapter (google for exact steps how to do it)!
About game - I don't think it's address problem, I think it's the problem with that function, returning wrong, empty or bad address! You have to think from other side - for example - Age of Empires III gets addresses just fine!
(In reply to Solerman Kaplon from comment #85)
I think the info here about the /etc/hosts is relevant: http://appdb.winehq.org/objectManager. php?sClass=version&iId=9180&iTestingId=34524
The game itself warns about having more than one address, it seems to bind to the first one, if it isn't the correct one it will not work. In linux, maybe the 127.* is the first one, which isn't going to work. Windows doesn't have that kind of address, so the first one should always be the first on a real adapter (eth* or wlan* kind of devices)
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #88 from Bruno Jesus 00cpxxx@gmail.com --- Please try again in wine 1.7.39 or later, there were changes related to the order of interfaces and IP values returned. If the problem persists get a new +iphlpapi,+winsock
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #89 from Leonardo José consoni_2519@hotmail.com --- Created attachment 51226 --> https://bugs.winehq.org/attachment.cgi?id=51226 +iphlpapi,+winsock trace (creating LAN game) with wine 1.7.40
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #90 from Leonardo José consoni_2519@hotmail.com --- Tried with wine 1.7.40 and the problem (Unable to establish connection when creating LAN game) still persists. Log attached.
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #91 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Leonardo José from comment #89)
Created attachment 51226 [details] +iphlpapi,+winsock trace (creating LAN game) with wine 1.7.40
Your log seems very short compared to others in the bug, maybe due to the lack of winetricks directplay?
https://bugs.winehq.org/show_bug.cgi?id=20041
Leonardo José consoni_2519@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #51226|0 |1 is obsolete| |
--- Comment #92 from Leonardo José consoni_2519@hotmail.com --- Created attachment 51236 --> https://bugs.winehq.org/attachment.cgi?id=51236 +iphlpapi,+winsock trace (creating LAN game) with wine 1.7.40 (winetricks directplay installed)
I'm sorry, here is the new trace after running "winetricks directplay". Fail happens earlier, when selecting LAN game option.
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #93 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Leonardo José from comment #92)
Thanks, that looks better. We need to resume Juan Lang's work and continue looking for the difference that makes the game reject the GetAdaptersAddresses return. I'll see what I can do.
https://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|wine-bugs@winehq.org |00cpxxx@gmail.com
--- Comment #94 from Bruno Jesus 00cpxxx@gmail.com --- Ok, just found the issue. I'll attach a patch for testing.
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #95 from Bruno Jesus 00cpxxx@gmail.com --- Created attachment 51240 --> https://bugs.winehq.org/attachment.cgi?id=51240 fill more config fields
Please try the attached patch, it should fix any DirectPlay8 bug that has problems starting the network in wine.
https://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |33423
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #96 from Leonardo José consoni_2519@hotmail.com --- I confirm it's possible to create a multiplayer LAN game with this patch. Thanks so much to everyone who worked on this long standing bug !
https://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch Summary|Multiplayer not working for |Multiplayer not working for |Rise of Nation Gold |Rise of Nation Gold | |(DirectPlay8 requires some | |IP_ADAPTER_UNICAST_ADDRESS | |parameters to be correct)
--- Comment #97 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Leonardo José from comment #96)
I confirm it's possible to create a multiplayer LAN game with this patch. Thanks so much to everyone who worked on this long standing bug !
Thanks for testing, I have to add more tests to prove the patch is OK so it may take some more days before finally fixing this. And thanks to Juan Lang for pointing the way to find the problem.
https://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
--- Comment #98 from Bruno Jesus 00cpxxx@gmail.com --- *** Bug 24010 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiplayer not working for |DirectPlay8 requires some |Rise of Nation Gold |IP_ADAPTER_UNICAST_ADDRESS |(DirectPlay8 requires some |parameters to be correct in |IP_ADAPTER_UNICAST_ADDRESS |GetAdaptersAddresses (Rise |parameters to be correct) |of Nations, Two Worlds, | |Cultures Northland)
https://bugs.winehq.org/show_bug.cgi?id=20041
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |9c20f9bca6996acc2ee1ddd4eec | |e36123da498cb Status|ASSIGNED |RESOLVED Resolution|--- |FIXED
--- Comment #99 from Bruno Jesus 00cpxxx@gmail.com --- Since the same patch was commited I'm resolving this as fixed by http://source.winehq.org/git/wine.git/?a=commit;h=9c20f9bca6996acc2ee1ddd4ee...
It would be useful if owners of RC Cars and Dungeon Siege could also give some feedback.
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #100 from Starous starous@volny.cz --- Hi Bruno, I am keeping my eyes on this thread, so I am planning to test your new patch on RC Cars game independent on your post. Unfortunately I am too busy in last time and it seems I will have time to test it approx. after one week - at the best (sorry). I will report result ASAP, I hope it will be positive. Thank You and Juan Lang in any case! BR, Ales
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #101 from Bruno Jesus 00cpxxx@gmail.com --- (In reply to Starous from comment #100)
Hi Bruno, I am keeping my eyes on this thread, so I am planning to test your new patch on RC Cars game independent on your post. Unfortunately I am too busy in last time and it seems I will have time to test it approx. after one week - at the best (sorry). I will report result ASAP, I hope it will be positive. Thank You and Juan Lang in any case!
Don't worry, take your time. And if the problem is not resolved please open a new bug.
https://bugs.winehq.org/show_bug.cgi?id=20041
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #102 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.41.
https://bugs.winehq.org/show_bug.cgi?id=20041
--- Comment #103 from Starous starous@volny.cz --- Just confirmation - I tried it in RC Cars game. It works! There are some troubles when more than one interface is used but it is another story. Thanks!
-
wine-bugs＠winehq.org