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@winehq.org Reporter: stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #1 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72854 --> https://bugs.winehq.org/attachment.cgi?id=72854 ipconfig /all output
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #2 from Hans Leidekker hans@meelstraat.net --- ipconfig uses GetAdaptersAddresses(), which does include the loopback interface on Windows.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #3 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #4 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #5 from Stanislav Slow stanislav.rimsha@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #6 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72855 --> https://bugs.winehq.org/attachment.cgi?id=72855 wine-5.0 debug log
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #7 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #8 from Hans Leidekker hans@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #9 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #10 from Stanislav Slow stanislav.rimsha@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #11 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #12 from Stanislav Slow stanislav.rimsha@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #13 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #14 from Stanislav Slow stanislav.rimsha@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!
https://bugs.winehq.org/show_bug.cgi?id=53499
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #15 from Olivier F. R. Dierick o.dierick@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
Olivier F. R. Dierick o.dierick@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 |
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #16 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #17 from Stanislav Slow stanislav.rimsha@gmail.com --- On windows each interface combination performs normally without any issues.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #18 from Hans Leidekker hans@meelstraat.net --- Created attachment 72891 --> https://bugs.winehq.org/attachment.cgi?id=72891 patch
Does this patch help?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #19 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #20 from Hans Leidekker hans@meelstraat.net --- Patch was committed as fa8a5692c28bd982cf90306383d6bd69f4da204e. Please let us know if the next Wine release (7.15) fixes this bug.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #21 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #22 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #23 from Stanislav Slow stanislav.rimsha@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #24 from Hans Leidekker hans@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
Julian Rüger jr98@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jr98@gmx.net
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #25 from Stanislav Slow stanislav.rimsha@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
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #26 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72928 --> https://bugs.winehq.org/attachment.cgi?id=72928 eth disconnected, wlan connected: ipconfig
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #27 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72929 --> https://bugs.winehq.org/attachment.cgi?id=72929 eth disconnected, wlan connected: debug log
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #28 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72933 --> https://bugs.winehq.org/attachment.cgi?id=72933 eth connected, wlan disconnected: ipconfig
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #29 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72934 --> https://bugs.winehq.org/attachment.cgi?id=72934 eth connected, wlan disconnected: debug log
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #30 from Stanislav Slow stanislav.rimsha@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
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #31 from Hans Leidekker hans@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #32 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72936 --> https://bugs.winehq.org/attachment.cgi?id=72936 Ethernet connected, wlan disconnected, LAN game works
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #33 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72937 --> https://bugs.winehq.org/attachment.cgi?id=72937 Ethernet disconnected, wlan connected, LAN game doesn't work
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #34 from Hans Leidekker hans@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?
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #35 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #36 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72946 --> https://bugs.winehq.org/attachment.cgi?id=72946 Ethernet disconnected and down, wlan connected, ifconfig
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #37 from Stanislav Slow stanislav.rimsha@gmail.com --- Created attachment 72947 --> https://bugs.winehq.org/attachment.cgi?id=72947 Ethernet disconnected and down, wlan connected, debug.log
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #38 from Stanislav Slow stanislav.rimsha@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.
https://bugs.winehq.org/show_bug.cgi?id=53499
--- Comment #39 from Stanislav Slow stanislav.rimsha@gmail.com --- I tested this issue with several machines and can confirm that disabling disconnected interfaces solves the issue.
https://bugs.winehq.org/show_bug.cgi?id=53499
SirAdams siradams@siradams.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |siradams@siradams.com
--- Comment #40 from SirAdams siradams@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