https://bugs.winehq.org/show_bug.cgi?id=40247
Bug ID: 40247 Summary: Wine returns bad MAC address for loopback interface, fails to run licensed programs. Product: Wine Version: unspecified Hardware: x86 OS: Mac OS X Status: UNCONFIRMED Severity: normal Priority: P2 Component: netcfgx Assignee: wine-bugs@winehq.org Reporter: alexchandel@gmail.com
There are some (poorly written) programs that base their licensing off the system's MAC address. Unfortunately, some of them are necessary for engineering work. These are old programs with brittle source but valid licenses that cannot be run because Wine cannot ever tell them what Windows would tell them.
Wine always returns a MAC address of "00:00:00:00:00:00" to these programs. I assume that's because the loopback interface is first in `ifconfig`, and thus is enumerated first to Windows programs by Wine, and has no MAC address.
In most cases, programs like these choose the MAC address of the first "network adapter" that would have been printed by `ipconfig /all`. Again, in Wine, the first such adapter printed is the loopback interface.
This problem can't be solved by normal MAC address spoofing techniques, because the loopback interface simply doesn't have a MAC address according to the host.
And Windows tricks to change the MAC address, like modifying the "NetworkAddress" key of "HKLM\System\CurrentControlSet\Control\Class{4d36e972-e325-11ce-bfc1-08002be10318}\XXXX", don't seem to have any effect in Wine. Particularly with respect to affecting the loopback interface.
There needs to be a Wine option, possibly a key somewhere in "HKLM\Software\Wine", to override (at the very least) the loopback interface's apparent MAC address, so that these programs can work.
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #1 from Bruno Jesus 00cpxxx@gmail.com --- Do you happen to know how the interfaces are being listed in these programs? If it is using winsock please try wine-staging as it has a patch related to fix a similar problem.
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #2 from alexchandel@gmail.com --- Actually I believe at least one uses NetApi32's Netbios function.
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #3 from alexchandel@gmail.com --- I tested the latest wine-staging. The issue still remains.
https://bugs.winehq.org/show_bug.cgi?id=40247
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #4 from alexchandel@gmail.com --- I did some tracing, and it's as I feared.
The program calls Netbios() with ncb_command=0x37 and ncb_lana_num=0, then with ncb_command=0x32 and ncb_lana_num=0, then with ncb_command=0x33 and ncb_lana_num=0. This eventually calls GetIfEntry(), which calls getInterfaceEntryByName(), which calls getInterfacePhysicalByName(), which (on my machine) calls sysctl().
sysctl returns an empty MAC address for the loopback interface, and Wine zeros out the rest of it (i.e. all 12 bytes).
No windows program will ever expect the first enumerated network adapter to be the loopback interface, and some old ones are hard-coded to require that the MAC address of the first adapter be known to the program's author.
Either the loopback interface should be skipped during enumeration, or Wine should return a default MAC address instead of a zeroed MAC address.
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #5 from alexchandel@gmail.com --- I retested this on Arch Linux and the issue didn't show up. Notably while `ip link` places the loopback first, `ifconfig` does not.
So this issue requires system-specific code for systems (like OS X) that do not report a different interface order under certain circumstances.
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #6 from alexchandel@gmail.com --- Bruno, would it be possible to introduce code moving the loopback interface to last on OS X, just like it is on Linux?
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #7 from Bruno Jesus 00cpxxx@gmail.com --- It certainly is possible to fix this, but if it depends on me I will only be able to work in this in July because my computer charger stopped working, so no more wine development from me until I go back home.
https://bugs.winehq.org/show_bug.cgi?id=40247
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=40247
--- Comment #8 from Bruno Jesus 00cpxxx@gmail.com --- I tried tracing back the called functions from your comments but could not find the culprit yet. A log with channels +netbios,+winsock,+iphlpapi,+relay,+tid would help. See more info about how to get the log at http://wiki.winehq.org/FAQ#get_log
Basically: WINEDEBUG=+netbios,+winsock,+iphlpapi,+relay,+tid wine <program_name.exe> >> /tmp/output.txt 2>&1
https://bugs.winehq.org/show_bug.cgi?id=40247
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|netcfgx |iphlpapi Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|Wine returns bad MAC |Wine returns the loopback |address for loopback |IP as first item in |interface, fails to run |GetIpAddrTable causing some |licensed programs. |licensed programs to fail | |due to invalid MAC address
--- Comment #9 from Bruno Jesus 00cpxxx@gmail.com --- I can see the problem now, the call comes from https://source.winehq.org/source/dlls/netapi32/nbt.c#1344
https://bugs.winehq.org/show_bug.cgi?id=40247
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |95298b4442504d9e977fbdb72ce | |1417273340265 Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #10 from Bruno Jesus 00cpxxx@gmail.com --- Fixed by http://source.winehq.org/git/wine.git/commitdiff/95298b4442504d9e977fbdb72ce...
https://bugs.winehq.org/show_bug.cgi?id=40247
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #11 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 2.0-rc1.
https://bugs.winehq.org/show_bug.cgi?id=40247
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |1.8.x
https://bugs.winehq.org/show_bug.cgi?id=40247
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |---
--- Comment #12 from Michael Stefaniuc mstefani@redhat.com --- Removing 1.8.x milestone from bugs included in 1.8.7.
https://bugs.winehq.org/show_bug.cgi?id=40247
oguz oguz.yayla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |oguz.yayla@gmail.com
--- Comment #13 from oguz oguz.yayla@gmail.com --- This problem still exists! wine returns an empty MAC address, which is the one belonging to lo interface.