http://bugs.winehq.org/show_bug.cgi?id=28268
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Component|wininet |iphlpapi Summary|Ashen Empires login fails |PixelMine Ashen Empires | |Launcher login fails | |(server-side ASP.NET code | |can't handle more than 5 | |host adapter MAC addresses | |returned from | |GetAdaptersInfo in auth | |request) Ever confirmed|0 |1
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello Liam,
I found the problem - it's not even a Wine bug.
Additionally to the authentication info (username, password and some other thing I couldn't quickly identify), the MAC addresses from all host network adapters are encoded in the 'POST' request.
The launcher uses GetAdaptersInfo() API to fetch the adapters info. It filters out all MIB_IF_TYPE_LOOPBACK type adapters and converts the MAC addresses from the remaining adapters to hex-strings before encoding the whole POST content.
Unfortunately there seems to be a hard limit on the server-side ASP.NET code (request handler) which just discards the requests if too many addresses found. The 'HTTP/1.1 400 Bad Request' was not really helpful, I had to do some testing to figure out the limit. Up to 5 adapter addresses are allowed until it responds with error code 400. Many Linux machines are multi NIC/homed and in my case 7 adapter addresses (including virtual NIC's) were being sent with the request.
After limiting it to 5 adapters by changing iphlpapi (or at runtime with the debugger), the login worked.
As already said, this is not the fault of Wine but a server side limit. Some guy writing the ASP.NET server code didn't think to deep about this (probably a matter of pay hehe).
You could modify Wine code to limit the number of adapter info structures returned by iphlpapi.GetAdaptersInfo() but I would advise against it because this influences Wine's behaviour globally, potentially affecting other software.
Options:
1) Notify the vendor and hoping for a fix on their side
2) Limit the number of 'seen' adapters locally with Linux tools (if/ifconfig)
3) Patch the installer itself.
This works (tested) but unfortunately triggers the auto-update functionality of the launcher each time (checksum). The patch would be reverted after restart unless more measures are taken - which qualifies for hacking.
In general the launcher works pretty fine with builtins. There was no native override needed - another testimony that Wine evolved.
Regards