[Bug 53499] New: GetAdaptersInfo returns loopback interface while it should omit it
https://bugs.winehq.org/show_bug.cgi?id=53499 Bug ID: 53499 Summary: GetAdaptersInfo returns loopback interface while it should omit it Product: Wine Version: 7.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: minor Priority: P2 Component: iphlpapi Assignee: wine-bugs(a)winehq.org Reporter: stanislav.rimsha(a)gmail.com Distribution: --- Created attachment 72853 --> https://bugs.winehq.org/attachment.cgi?id=72853 Application debug log with +iphlpapi,+nsi,+winsock I'm trying to fix LAN play under wine for a game for some time and in the logs I came across the issue that GetAdaptersInfo seems to include loopback interface and causing application to use zero hardware address (loopback interface is always on top). According to the code here loopback interfaces should not be included: https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/iphlpapi/iphlpapi_mai... However in debug log interface indexes indicate that loopback is likely returned along with other adapters. Also worth noting that in ipconfig /all the lo interface is considered an Ethernet interface. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #1 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72854 --> https://bugs.winehq.org/attachment.cgi?id=72854 ipconfig /all output -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #2 from Hans Leidekker <hans(a)meelstraat.net> --- ipconfig uses GetAdaptersAddresses(), which does include the loopback interface on Windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #3 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #2)
ipconfig uses GetAdaptersAddresses(), which does include the loopback interface on Windows.
No problem with the ipconfig showing the loopback interface. I only added the ipconfig info to show that the loopback is considered an ethernet interface. Which might be the issue in the first place - it's not being skipped because wine sees it as ethernet and not loopback. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #4 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Stanislav Slow from comment #3)
(In reply to Hans Leidekker from comment #2)
ipconfig uses GetAdaptersAddresses(), which does include the loopback interface on Windows.
No problem with the ipconfig showing the loopback interface. I only added the ipconfig info to show that the loopback is considered an ethernet interface. Which might be the issue in the first place - it's not being skipped because wine sees it as ethernet and not loopback.
But GetAdaptersInfo() (which is called in your log) doesn't include the loopback interface. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #5 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #4)
(In reply to Stanislav Slow from comment #3)
(In reply to Hans Leidekker from comment #2)
ipconfig uses GetAdaptersAddresses(), which does include the loopback interface on Windows.
No problem with the ipconfig showing the loopback interface. I only added the ipconfig info to show that the loopback is considered an ethernet interface. Which might be the issue in the first place - it's not being skipped because wine sees it as ethernet and not loopback.
But GetAdaptersInfo() (which is called in your log) doesn't include the loopback interface.
Can you tell that from the log? You might be right because I don't have any direct proof for that. I only get an issue that all Wine clients on LAN identify themselves with the same ID which is likely to be the hardware address of the primary interface, while windows clients can distinguish themselves with no problem. The only difference in the network configuration is the presence of the lo interface on linux machines. There were similar issues reported earlier in other dlls: https://bugs.winehq.org/show_bug.cgi?id=40247#c13 I can't tell exactly from the application log where does it get the id to use, previous logs from wine-5.0 showed only the GetAdaptersInfo calls and winsock bindings to interface indexes that were implying there 3 interfaces total, while there are only 2 physical and one loopback. I somehow sticked to the idea that GetAdaptersInfo even after updating to 7.14 and seeing the same behavior. I'm adding wine-5.0 log for the same application, maybe you could point me to the right direction then? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #6 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72855 --> https://bugs.winehq.org/attachment.cgi?id=72855 wine-5.0 debug log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #7 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Stanislav Slow from comment #5)
(In reply to Hans Leidekker from comment #4)
(In reply to Stanislav Slow from comment #3)
(In reply to Hans Leidekker from comment #2)
ipconfig uses GetAdaptersAddresses(), which does include the loopback interface on Windows.
No problem with the ipconfig showing the loopback interface. I only added the ipconfig info to show that the loopback is considered an ethernet interface. Which might be the issue in the first place - it's not being skipped because wine sees it as ethernet and not loopback.
But GetAdaptersInfo() (which is called in your log) doesn't include the loopback interface.
Can you tell that from the log? You might be right because I don't have any
No but in the source you pointed out loopback interfaces are skipped. Running the iphlpapi tests also confirms it.
direct proof for that. I only get an issue that all Wine clients on LAN identify themselves with the same ID which is likely to be the hardware address of the primary interface, while windows clients can distinguish themselves with no problem. The only difference in the network configuration is the presence of the lo interface on linux machines. There were similar issues reported earlier in other dlls: https://bugs.winehq.org/show_bug.cgi?id=40247#c13
You should try to figure out where this ID comes from. Is it a MAC address? In that case I would expect an all-zero ID if for the loopback address. Perhaps a +relay trace will tell us more. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #8 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Stanislav Slow from comment #5)
I'm adding wine-5.0 log for the same application, maybe you could point me to the right direction then?
Are you saying this worked in wine-5.0? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #9 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #7)
You should try to figure out where this ID comes from. Is it a MAC address? In that case I would expect an all-zero ID if for the loopback address. Perhaps a +relay trace will tell us more.
I tried adding +relay but it left me with a half gig log after filtering with RelayExclude as per instructions on Debug page. Not sure I can read through that much logs. (In reply to Hans Leidekker from comment #8)
(In reply to Stanislav Slow from comment #5)
I'm adding wine-5.0 log for the same application, maybe you could point me to the right direction then?
Are you saying this worked in wine-5.0?
No, I'm saying that I first encountered the issue under wine-5.0 and iphlpapi debug looked like it was the GetAdaptersInfo where loopback was present, that's where I got the idea first. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #10 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #7)
You should try to figure out where this ID comes from. Is it a MAC address? In that case I would expect an all-zero ID if for the loopback address. Perhaps a +relay trace will tell us more.
Are there any specific keywords I could grep from log to prove or disprove the theory? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #11 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Stanislav Slow from comment #10)
(In reply to Hans Leidekker from comment #7)
You should try to figure out where this ID comes from. Is it a MAC address? In that case I would expect an all-zero ID if for the loopback address. Perhaps a +relay trace will tell us more.
Are there any specific keywords I could grep from log to prove or disprove the theory?
Following your theory about client IDs you could try to capture network packets from the game running on Windows and identify this ID. Then grep for strings with same format, or stuff surrounding it. More generally comparing packets from clients running on Windows and Wine and see where they diverge may a good approach. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #12 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #11)
Following your theory about client IDs you could try to capture network packets from the game running on Windows and identify this ID. Then grep for strings with same format, or stuff surrounding it.
More generally comparing packets from clients running on Windows and Wine and see where they diverge may a good approach.
I finally made things work properly (somewhat) and found the culprit. I have connected one of the machines via ethernet while the second linux machine is connected via wlan. They were able to see each other with no problem. I have checked the logs again and the difference was that winsock did not try to bind to 0.0.0.0 and only bound to LAN address. Therefore I suppose that the client ID is the primary binding IP. The question now is - why does it try to bind to a DOWN state interface under wine but doesn't do it on windows? Does GetAdaptersInfo supply state info? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #13 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Stanislav Slow from comment #12)
The question now is - why does it try to bind to a DOWN state interface under wine but doesn't do it on windows? Does GetAdaptersInfo supply state info?
It doesn't. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #14 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #13)
(In reply to Stanislav Slow from comment #12)
The question now is - why does it try to bind to a DOWN state interface under wine but doesn't do it on windows? Does GetAdaptersInfo supply state info?
It doesn't.
Then the issue may be in the getIfEntry method which should supply the interface status (according to microsoft docs) and is called right before binding. I can open another issue on that if thats ok. And you can close this one since I was wrong about the GetAdaptersInfo. Thanks for helping me investigating this case! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick(a)piezo-forte.be --- Comment #15 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Stanislav Slow from comment #14)
(In reply to Hans Leidekker from comment #13)
(In reply to Stanislav Slow from comment #12)
The question now is - why does it try to bind to a DOWN state interface under wine but doesn't do it on windows? Does GetAdaptersInfo supply state info?
It doesn't.
Then the issue may be in the getIfEntry method which should supply the interface status (according to microsoft docs) and is called right before binding. I can open another issue on that if thats ok. And you can close this one since I was wrong about the GetAdaptersInfo.
Thanks for helping me investigating this case!
Hello, You may recycle this bug as the issue is the same, it was just misdiagnosed. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|GetAdaptersInfo returns |Wine binds to wrong |loopback interface while it |interface for LAN play. |should omit it | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #16 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Olivier F. R. Dierick from comment #15)
Hello,
You may recycle this bug as the issue is the same, it was just misdiagnosed.
Regards.
Thank you. I'm investigating the issue further and now I tried to start LAN game with both ethernet and wlan enabled. The application successfully binds to both interfaces on valid addresses instead of 0.0.0.0 and works normally. When I have only ethernet interface enabled the game binds to its valid IP and doesn't try to bind to WLAN. LAN game works normally. When I have only wlan enabled and ethernet physically disconnected (DOWN state) the game still attempts to bind on invalid IP 0.0.0.0 and valid wlan IP. LAN game doesn't work normally in this case. ipconfig /all shows all interfaces as enabled even with ethernet disconnected physically. On windows ipconfig shows a disconnected ethernet as disabled interface. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #17 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- On windows each interface combination performs normally without any issues. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #18 from Hans Leidekker <hans(a)meelstraat.net> --- Created attachment 72891 --> https://bugs.winehq.org/attachment.cgi?id=72891 patch Does this patch help? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #19 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #18)
Created attachment 72891 [details] patch
Does this patch help?
I'm sorry, but I'm not smart enough to build a biarch wine from source with this patch :/ I can test it once it reaches staging branch build though, if you are going to merge it there. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #20 from Hans Leidekker <hans(a)meelstraat.net> --- Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #21 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #20)
Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
Thank you! I will report back once next release is available. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #22 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #20)
Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
Today I updated to 7.15 and debug log confirms that the issue is still there - app attempts to bind on 0.0.0.0 when ethernet is inactive, but binds to correct ethernet address when its active. Also ipconfig still not listing any interfaces as disabled. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #23 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #20)
Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
Do I need to recreate the prefix to test the patch? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #24 from Hans Leidekker <hans(a)meelstraat.net> --- (In reply to Stanislav Slow from comment #23)
(In reply to Hans Leidekker from comment #20)
Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
Do I need to recreate the prefix to test the patch?
No, I don't expect that to be necessary. Can you attach a +iphlpapi,+nsi,+winsock log from the configuration that works, as well as the output of ifconfig for both cases? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 Julian Rüger <jr98(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98(a)gmx.net -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #25 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #24)
(In reply to Stanislav Slow from comment #23)
(In reply to Hans Leidekker from comment #20)
Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
Do I need to recreate the prefix to test the patch?
No, I don't expect that to be necessary. Can you attach a +iphlpapi,+nsi,+winsock log from the configuration that works, as well as the output of ifconfig for both cases?
Sure, I'll collect the logs and attach them here today -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #26 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72928 --> https://bugs.winehq.org/attachment.cgi?id=72928 eth disconnected, wlan connected: ipconfig -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #27 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72929 --> https://bugs.winehq.org/attachment.cgi?id=72929 eth disconnected, wlan connected: debug log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #28 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72933 --> https://bugs.winehq.org/attachment.cgi?id=72933 eth connected, wlan disconnected: ipconfig -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #29 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72934 --> https://bugs.winehq.org/attachment.cgi?id=72934 eth connected, wlan disconnected: debug log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #30 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #24)
(In reply to Stanislav Slow from comment #23)
(In reply to Hans Leidekker from comment #20)
Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
Do I need to recreate the prefix to test the patch?
No, I don't expect that to be necessary. Can you attach a +iphlpapi,+nsi,+winsock log from the configuration that works, as well as the output of ifconfig for both cases?
I have attached all the logs you mentioned. When ethernet is connected and wlan is disconnected - this is the configuration that works. Added the other one for comparison on 7.15 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #31 from Hans Leidekker <hans(a)meelstraat.net> --- I meant Linux ifconfig, not ipconfig. The latter is not really interesting because it may use different APIs and have bugs of its own. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #32 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72936 --> https://bugs.winehq.org/attachment.cgi?id=72936 Ethernet connected, wlan disconnected, LAN game works -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #33 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72937 --> https://bugs.winehq.org/attachment.cgi?id=72937 Ethernet disconnected, wlan connected, LAN game doesn't work -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #34 from Hans Leidekker <hans(a)meelstraat.net> --- In the case where the wlan interface is connected the ethernet interface is still up and running, without an associated IP address. In the working case where the ethernet interface is connected the wlan interface is down. What happens if you shut down the ethernet interface in the first configuration? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #35 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- (In reply to Hans Leidekker from comment #34)
In the case where the wlan interface is connected the ethernet interface is still up and running, without an associated IP address. In the working case where the ethernet interface is connected the wlan interface is down.
What happens if you shut down the ethernet interface in the first configuration?
The interface is disconnected physically and ip link shows it in DOWN state. I'll try to set it DOWN explicitly and come back with results then. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #36 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72946 --> https://bugs.winehq.org/attachment.cgi?id=72946 Ethernet disconnected and down, wlan connected, ifconfig -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #37 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- Created attachment 72947 --> https://bugs.winehq.org/attachment.cgi?id=72947 Ethernet disconnected and down, wlan connected, debug.log -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #38 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- It seems when I set the ethernet interface down explicitly with ip link set down the game only binds once and receives a proper IP. I can't test the lan game properly now because of the lack of machines at hand, but this workaround seems to solve the issue. I will report back as soon as I have a chance to test it with multiple machines. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 --- Comment #39 from Stanislav Slow <stanislav.rimsha(a)gmail.com> --- I tested this issue with several machines and can confirm that disabling disconnected interfaces solves the issue. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53499 SirAdams <siradams(a)siradams.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |siradams(a)siradams.com --- Comment #40 from SirAdams <siradams(a)siradams.com> --- I have the same problem with Debian 11 and Wine 5.0, Wine 8.0, Wine 8.5. ipconfig 0060:fixme:nsi:ipv6_forward_enumerate_all not implemented 0060:fixme:nsi:ipv6_forward_enumerate_all not implemented Ethernet adapter lo Przedrostek DNS danego połączenia : Adres IPv6. . . . . . . . . . . . : ::1 Adres IPv4. . . . . . . . . . . . : 127.0.0.1 Brama domyślna. . . . . . . . . . : Ethernet adapter eth0 Przedrostek DNS danego połączenia : Adres IPv6. . . . . . . . . . . . : 2001:x:: Adres IPv6. . . . . . . . . . . . : fe80::f816:3eff:fe0a:f25f%2 Adres IPv4. . . . . . . . . . . . : x.x.x.x Brama domyślna. . . . . . . . . . : x.x.x.x The program I am trying to run takes the first interface from the list. And at the moment there is no option to force another IP address. In Windows 10, the Interface that has output to the Internet is in first place and the application chooses it first. Just add an option that would allow you to select one interface with which Wine should work without the rest and I think that it would be solved many problems of users, for example --use-interface=eth0 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla