[Linux] issues with Patch 6.2.4 (Consolidated Issues Thread) R09

Technical Support
1 2 3 26 Next
Marked As Solution
Last Update: R09 (Final)

Update Log:
R09: Noted that this issue is patched in the latest versions of Wine. The issue should now be considered closed.
R08: Rewrote most of the Issue #2 section as we now know exactly what causes the problem and there are several ways to fix it.
R07: Added references to the wine patch that has been developed; improved the writing of the Ubuntu fixes.
R06: Added a candidate fix for Debian
R05: Understanding of issue #2 is maturing; several people have been able to fix the issue. We do not yet have a simple set of resolution directions, but we are getting closer. Also removed two requested feedback fields as they were deemed irrelevant.
R04: We have a possible resolution path for Issue #2! Additional testing is needed, but we may have this one fixed soon.
R03: Significant rewrite of section on Issue #2 as we've learned more about the problem and are getting closer to resolution.
R02: Added a question for whether the user is using an Authenticator as Issue #2 happens fairly early in the authentication process.
R01: Original Post.

Many Linux users (my current count is about 60-70) have reported issues of being unable to connect to and play World of Warcraft since the release of Patch 6.2.4. These issues seem to fall into two different categories, which seem to have different troubleshooting steps. Because Blizzard does not officially support Linux, we are left to fend for ourselves in terms of achieving resolution, but the devs looked into it last night and there wasn't any changes in 6.2.4 that were believed to specifically break the application's ability to run in wine.

This thread is a fork/consolidation of several other threads on the subject:

This post (first in the thread) has been periodically updated as more information became available. For the sake of convenience, the thread title was updated (R01, R02, R03, etc.) when there was a significant development.

Issue #1: Error Code BLZ51900007
Upon attempting to log-in, user immediately receives the following error: "You have been disconnected (BLZ51900007)" and is returned to the log-in screen. (Screenshot: http://imgur.com/rhFslBw ) If you are not seeing this specific error message, proceed to issue #2, this does not apply to you.

This is the issue I was personally having yesterday. The fix for this error appears to be to update to the latest version of Wine (1.9.7 or newer). Directions for how to do this can be found at https://www.winehq.org/download or from your distribution's support pages. If you are using PlayOnLinux or Crossover Office, verify which version of wine is being used underneath before submitting reports.

At this point, it does not appear that anyone using the current version of Wine is receiving this error message upon attempting to log in (the four people who have reported this error are all either able to play now or are now experiencing issue #2 instead.)

Issue #2: Client gets stuck on "Connecting" indefinitely
Upon attempting to log-in, client gets stuck at "Connecting" indefinitely; may eventually time out or remain with this message on the screen until the user manually cancels the log-in process. (Screenshot from Raejien: http://imgur.com/TBYOAbY ) There is no specific error code or disconnect message.

This seems to be the issue affecting the majority of users that have posted reports. We have identified that the cause of this issue is in secur32.dll.so, a wine library that implements encryption on the network stack for Windows applications. secur32.dll.so directs gnutls (the Linux library which actually implements the functionality) to perform an SSLv3 handshake with the server by default. This was acceptable behavior in prior versions of WoW but 6.2.4 removed tolerance for it, resulting in the client being abruptly dropped by the server, which now requires TLS (a newer encryption paradigm) only.

To use a non-technical analogy, in prior versions of WoW, the visitor to the WoW club would first need to demonstrate the secret handshake to the guard, then provide their password to access. Patch 6.2.4 changed the rules; wine continues to use the old secret handshake which results in the guard slamming the door on you.

Complicating our efforts to identify the problem was that gnutls actually dropped support for the SSLv3 handshake in a recent version anyway, resulting in many users (myself included) never even experiencing this issue, as it ignored wine's instructions to use SSLv3 and engaged via TLS by default, making the issue moot.

Because of this, there are actually two fairly different ways to address this issue and get your game working if you are having this problem. The first is to update your distribution to use a recent version of gnutls, then purge/reinstall wine to link against the newer version. The second is to patch secur32.dll.so so that wine does not attempt to engage in the invalid login behavior. Both of these methods have their merits and reasonable arguments.

Update Method
The update method is confirmed to work for Ubuntu, ArchLinux, Gentoo and Debian and should be viewed as the more "official" approach. The benefits of the update method are that it does not require installing any unofficial wine patches, building wine from source or doing anything especially complicated.

The main down-sides are that it may take longer (particularly for Gentoo) and for some distributions that have a slower release cycle (e.g. Linux Mint, Red Hat, Ubuntu LTS, OpenSuSE, etc.) it may not even be an option as the relevant gnutls binaries may not be available. Directions for how to do this on the distributions where there is a known good method are further down. Be sure you back-up any important files before performing a distribution upgrade as sometimes distribution upgrades can cause unexpected problems.

Patch Method
This method will probably work for all Linux distributions, although binaries have not been precompiled for all distributions. This method's main advantages are that it fills the void left by the lack of an update method for some distributions and that it's pretty simple (it summarizes to download and replace a file). Its main disadvantage is that you will either have to build wine from source (the discussion of this begins on page 11) or download a binary library that may not be optimized for your computer or could break your wine installation or cause issues with Windows applications that depend on the legacy behavior (a binary version is available on page 16 of this thread).

Issue #2 Update Method for Ubuntu
The update method for Ubuntu requires updating your distribution to the current stable version (15.10). If you are using the 14.04 LTS version, this will mean forgoing LTS, although you could instead upgrade to 16.04 LTS. Note that 16.04 does not currently support 3D acceleration on Radeon chips out of the box; be aware of this if opt to go that route and use a Radeon video card.

To upgrade to 15.10 (the recommended method), follow the directions for upgrading your distribution at https://help.ubuntu.com/lts/serverguide/installing-upgrading.html

To upgrade to 16.04 LTS, a guide is available here: http://itsfoss.com/upgrade-ubuntu-16-04/

After the update is complete, execute the following:
sudo apt-get purge wine1.7
sudo apt-get purge wine-gecko2.34
sudo apt-get purge wine-mono4.5.4
sudo apt-get purge winetricks
sudo apt-get purge winehq-devel

sudo dpkg --add-architecture i386
sudo add-apt-repository ppa:wine/wine-builds
sudo apt-get update
sudo apt-get install --install-recommends winehq-devel

Issue #2 Update Method for Debian
It's not clear this issue can be easily fixed in Debian without switching to the testing branch. Switching to the branch and updating all packages seems to work. You can do this by editing /etc/apt/sources.list and anything in /etc/apt/sources.list.d/ -- replace "jessie" or "stable" with "stretch" or "testing" for everything except wine itself, which requires "stretch".

Once that's done, run the following:
apt-get update
apt-get -y dist-upgrade

Issue #2 Update Method for Gentoo
Execute the following commands and wait for each to complete before moving on to the next. (This will take a long time.)

emerge -vuND world
emerge -C app-emulation/wine
emerge app-emulation/wine

Success cases
Having fully identified the problem, we have been able to get the game working for nearly everyone that has reported issues; any remaining issues are not Linux-specific and outside the scope of this thread. Note that Wine 1.9.7 introduced a fix for the problem that was identified via this thread; some earlier versions of Wine (such as 1.9.4-1.9.6) will probably work as well provided that you have the current version of gnutls installed on your system, but if you're using the dev release of Wine you might as well use the latest version anyway.

Special Thanks
A lot of talented people have contributed heavily so far to this thread. Special mention goes to the following: Cashus, Enervé, Fraggy, Harju, Maldron, Panwe, Pontudinho, Rootsuid, Sciamana, Serensis, Store and Symax. Thank you all so much for your assistance. This is what Free Software is all about--people helping each-other. :D
Desktop setup is stuck with Issue #2:

1. I use CrossOver 15.0.1 instead of a wine solution.

2. 3.19.0-32-generic(x64)

3. Linux Mint KDE 17.3

4. Issue#2, stuck connecting.

5. 32-bit WINEPREFIX

6. Logs show this error at connection: [IBN_Login] Front disconnected | connectionId=1 | result=( | code=ERROR_OK (0) | localizedMessage= | debugMessage=)

The initial error was a problem doing the update, so I did a clean install. After the clean install the connecting problem popped up.
I'm gonna add this here too.

There was reports on Wine HQ of a network communication issue, a syn/ack hanging with empty data. This appears true. In my testing (wireshark) i noticed something odd.

After the inital handshake, ACK, SYN/ACK ... there is a flood of Duplicate ACKs out of sequence when suck on connection.

Affected ACKs originate from:

blizdist1-a.akamaihd.net and a1219.d.akamai.net

This repeats 3 times.

This may be related, connection starts and then this happens...after the 3 attempt cycle, it fails quiet.

(Linux, LTS Kernel, Wine 1.9.6)
I've got wine 1.9.6. (direct RPM installl from RPM fusion) With or without the overrides that you list I get a DLL not found error. I've yet to be able to figure out which. I've gone around running attrib /S /D -H dir\*.* against the Battle.net, Battle.net.9* and World of Warcraft locations as has fixed this in the past with no luck. Launcher will run in XP mode, wow doesn't run in either XP or Win 7 modes.

Anyone having the same issue?
Wine Version: 1.9.6
WinePrefix: x86

Kernel: 4.4.5-1-ARCH x64

OS: Arch x64

No issues, game running smoothly.

WinePrefix: x86

I used PlayOnLinux until the issues, now I run Wow.exe directly through the terminal.

*msvcr90 (native,builtin)
d3d_compiler (disabled)
dbghelp (native,builtin)
msvcp100 (native,builtin)

Here's my ipv4 settings that were requested in another post: http://pastebin.com/QKuSj1xD
03/23/2016 09:44 AMPosted by Enervé
I'm gonna add this here too.

Hey Enervé, I was going through your post history and I noticed that you made this post:
03/22/2016 10:32 PMPosted by Enervé
Same issue here....

on my prior thread ( http://us.battle.net/wow/en/forum/topic/20742845120#16 )

Are you getting the error message described in Issue #1 or the stuck at connection (issue #2)?
Connection issue, just hangs.... been going through wireshark logs atm.

I do also wonder If kernel versions could be the issue, I'm sitting on the LTS 3.16 kernel atm.
03/23/2016 10:59 AMPosted by Enervé
I do also wonder If kernel versions could be the issue, I'm sitting on the LTS 3.16 kernel atm.

All three of the machines that have been confirmed working with WoW at this point for which I have a kernel version have a kernel newer than 4.2. Not enough people have posted their kernel version yet to know whether there is any significance to that fact, though.
Agreed.... I'm also chasing another theory atm,

TLS, or more specifically versions of TLS. Since the Wow-64.exe is communicating on the wire with TLS 1.2 (so says wireshark) that I'm wondering if there is a breakdown in cyrpto handling.

I may be chasing the dragon on this one, but im gonna do some regression and progession testing on a VM.

(This thread right here is why blizzard should support linux, Linux users know how to fix and troubleshoot issues... unlike certain OS users :) not naming names :P )
Confirmed that kernel is not the issue, booted into LTS and it still worked for me.
uname -a in a terminal please...

curious to know which LTS branch you are on.
03/23/2016 11:32 AMPosted by Fraggy
Confirmed that kernel is not the issue, booted into LTS and it still worked for me.

`uname -a` or `cat /proc/version`?
Battlenet.log file for Issue 2. Note connection.log hasn't been updated since I was last connected...

(Without Launcher)

3/23 13:50:11.976 [IBN_Login] Starting up | hasFrontInterface=false | hasBackInterface=false
3/23 13:50:24.717 [GlueLogin] Starting login | launcherPortal=nullopt | loginPortal=US.actual.battle.net:1119
3/23 13:50:24.717 [GlueLogin] Resetting
3/23 13:50:24.717 [IBN_Login] Initializing
3/23 13:50:24.717 [IBN_Login] Attempting logon | host=US.actual.battle.net | port=1119
3/23 13:50:24.719 [GlueLogin] Waiting for server response.
3/23 13:50:24.929 [IBN_Login] Front disconnected | connectionId=1 | result=( | code=ERROR_OK (0) | localizedMessage= | debugMessage=)
3/23 13:50:24.929 [GlueLogin] Disconnected from authentication server.
3/23 13:50:48.503 [GlueLogin] Explicitly disconnecting from realm server
3/23 13:50:48.667 [IBN_Login] Destroying | isInitialized=true
3/23 13:50:48.835 [IBN_Login] Shutting down

(with Launcher)

3/23 13:59:10.467 [IBN_Login] Starting up | hasFrontInterface=false | hasBackInterface=false
3/23 13:59:34.116 [GlueLogin] Starting login | launcherPortal=us.actual.battle.net | loginPortal=us.actual.battle.net:1119
3/23 13:59:34.116 [GlueLogin] Resetting
3/23 13:59:34.116 [IBN_Login] Initializing
3/23 13:59:34.116 [IBN_Login] Attempting logon | host=us.actual.battle.net | port=1119
3/23 13:59:34.117 [GlueLogin] Waiting for server response.
3/23 13:59:34.416 [IBN_Login] Front disconnected | connectionId=1 | result=( | code=ERROR_OK (0) | localizedMessage= | debugMessage=)
3/23 13:59:34.416 [GlueLogin] Disconnected from authentication server.
3/23 13:59:47.813 [GlueLogin] Explicitly disconnecting from realm server
3/23 13:59:48.765 [IBN_Login] Destroying | isInitialized=true
3/23 13:59:48.956 [IBN_Login] Shutting down
I was running 4.1.20
I'm curious how many Linux users, with issue #2, are like me and like to launch wow as "wine Wow-64.exe" (or otherwise bypass the Blizzard Launcher)... Well with this update, Wow-64.exe tries and fails to patch itself it may have even corrupted some files. This could explain the problem effecting a Windows user too.
03/23/2016 12:04 PMPosted by Fraggy
I was running 4.1.20

The emergent hypothesis that 3.x kernels are the source of the problem has not been disproven, then...

Enerve, do you think you could make an install medium for 15.10 and see if you can log in on it?
1.wine-1.6.2 - 32bit
2.Linux version 3.13.0-37-generic (x64)
3.Linux Mint 17.4
6.Delete indices/patch folder/*.exe;repair install; system updates; reboot;
7.none/not sure
Is there a single perk to using Linux with Wine over Windows? I was looking into this and it seemed to be more of a hassle than anything else.
yeah, the perk is: we don't have to use windows.
Wine 1.8 64
Linux mint kde 17.3

Issue #2 hangs at connection screen, working just fine before the patch, on linux, everything the same, So how can Blizzard say, its nothing on their end, when just 2 nights ago my game worked fine?? This needs to be Addressed, if not, and the sole reason is because I choose Linux, over a Cattle herding OS... I will just un-sub, not only will I, but I'll take a good bit with me.. This needs to be fixed, to blow it off, just because most of your base uses, a slave to master OS, is just wrong. Please fix the problem.

Join the Conversation

Return to Forum