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

Technical Support
Prev 1 9 10 11 26 Next
I think the problem is gnutls, in some versions it will send by default 0300h (=SSLv3) as the Protocol Version for the ClientHello message, unless you specify %LATEST_RECORD_VERSION in the gnutls priority string, in which case it will send 0303h (=TLS-1.2) instead.

The battlenet server seems to be dropping connections that specify SSLv3 in ClientHello immediately without a response.

Looking through the gnutls changelogs it seems they have changed the default behavior from SSLv3 to TLS-1.2, though they seem to have reverted the change at one point.

For WoW, wine passes the security string:
1 2016-03-24 01:34:01 trace:secur32:schan_imp_create_session Using "NORMAL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:-VERS-SSL3.0" priority

I suspect if it were to pass instead:
"NORMAL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:-VERS-SSL3.0:%LATEST_RECORD_VERSION"

That it would at least get a bit further in the login process.

Could anyone with a working connection open 2 terminals, in the first run
nc -l -p 1119 | xxd

And in the second terminal run:

gnutls-cli -V -d 9999 -p 1119 --priority 'NORMAL:-VERS-SSL3.0:-VERS-SSL3.0:-VERS-SSL3.0' localhost

and post the first 3 bytes from the first window that was running netcat (nc).

I suspect for working connections you would get 1603 03

And for non-working connections you would get 1603 00
On a working Ubuntu 15.10, first 3 bytes are 160301
On my non-working Mint 13, first 3 bytes are 160300

Working netcat:
00000000: 1603 0101 0b01 0001 0703 0356 f437 28a4 ...........V.7(.
00000010: 8a43 bd5f 1628 1ebb 83d9 9019 736e 048b .C._.(......sn..
00000020: 8867 9b98 ddb6 67ea 481b e400 0084 c02b .g....g.H......+
00000030: c02c c086 c087 c009 c023 c00a c024 c072 .,.......#...$.r
00000040: c073 c008 c007 c02f c030 c08a c08b c013 .s...../.0......
00000050: c027 c014 c028 c076 c077 c012 c011 009c .'...(.v.w......
00000060: 009d c07a c07b 002f 003c 0035 003d 0041 ...z.{./.<.5.=.A
00000070: 00ba 0084 00c0 000a 0005 0004 009e 009f ................
00000080: c07c c07d 0033 0067 0039 006b 0045 00be .|.}.3.g.9.k.E..
00000090: 0088 00c4 0016 00a2 00a3 c080 c081 0032 ...............2
000000a0: 0040 0038 006a 0044 00bd 0087 00c3 0013 .@.8.j.D........
000000b0: 0066 0100 005a 0005 0005 0100 0000 0000 .f...Z..........
000000c0: 0000 0e00 0c00 0009 6c6f 6361 6c68 6f73 ........localhos
000000d0: 74ff 0100 0100 0023 0000 000a 000c 000a t......#........
000000e0: 0017 0018 0019 0015 0013 000b 0002 0100 ................
000000f0: 000d 001c 001a 0401 0402 0403 0501 0503 ................
00000100: 0601 0603 0301 0302 0303 0201 0202 0203 ................
0301h is TLS-v1.0

Maybe they're only blocking SSLv3.
03/24/2016 11:46 AMPosted by Store
I think the problem is gnutls, in some versions it will send by default 0300h (=SSLv3) as the Protocol Version for the ClientHello message, unless you specify %LATEST_RECORD_VERSION in the gnutls priority string, in which case it will send 0303h (=TLS-1.2) instead.

The battlenet server seems to be dropping connections that specify SSLv3 in ClientHello immediately without a response.

Looking through the gnutls changelogs it seems they have changed the default behavior from SSLv3 to TLS-1.2, though they seem to have reverted the change at one point.

For WoW, wine passes the security string:
1 2016-03-24 01:34:01 trace:secur32:schan_imp_create_session Using "NORMAL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:-VERS-SSL3.0" priority

I suspect if it were to pass instead:
"NORMAL:+VERS-TLS1.2:+VERS-TLS1.1:+VERS-TLS1.0:-VERS-SSL3.0:%LATEST_RECORD_VERSION"

That it would at least get a bit further in the login process.

Could anyone with a working connection open 2 terminals, in the first run
nc -l -p 1119 | xxd

And in the second terminal run:

gnutls-cli -V -d 9999 -p 1119 --priority 'NORMAL:-VERS-SSL3.0:-VERS-SSL3.0:-VERS-SSL3.0' localhost

and post the first 3 bytes from the first window that was running netcat (nc).

I suspect for working connections you would get 1603 03

And for non-working connections you would get 1603 00


I have a non-working one and yes, I did see:

1603 00 for the first 3 bytes.
03/24/2016 03:28 AMPosted by Castoreum
whats the point of installing 15.10? in less than 30 days, the new long term support edition comes out.
installing 15.10 isn't hard, but whats the point if the newest lts is less than 30 days away?
it seems like it would make sense just to wait it out and see if the wow bugs get fixed

The release date of Ubuntu 16.04 LTS is set for April 21, 2016. Codenamed 'Xenial Xerus', Ubuntu 16.04 will be the 6th Long Term Support release of the hugely popular open-source operating system.


16.04 will not support fglrx, which is nontrivial for radeon users: http://www.omgubuntu.co.uk/2016/03/ubuntu-drops-amd-catalyst-fglrx-driver-16-04
Stuck on "Connecting" also

Linux 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
wine-1.7.18

# WoW launched via following:

$ env WINEPREFIX="/home/adrn/.wine" WINEDEBUG=-all __GL_THREADED_OPTIMIZATIONS=1 wine64 /home/foo/.wine/drive_c/Program\ Files\ \(x86\)/World\ of\ Warcraft/Wow-64.exe -opengl

WARNING: gnome-keyring:: couldn't connect to: /tmp/keyring-RzTcBo/pkcs11: No such file or directory
# ^^-- have always had that line show up if running Wow-64.exe from command line

# freezes on CONNECTING; have authenticator, but never get to that stage of login
# Deliberately entering wrong password changes nothing
# Following shows up after cancelling login & quitting

[format/1] [..\src\format.cpp:1430]: invalid length modifier for format 'u' in 'Client net stats: %Lu bytes sent, %Lu bytes received, %Lu msec elapsed' (ignored)
[format/1] [..\src\format.cpp:1430]: invalid length modifier for format 'u' in 'Client net stats: %Lu bytes sent, %Lu bytes received, %Lu msec elapsed' (ignored)
[format/1] [..\src\format.cpp:1430]: invalid length modifier for format 'u' in 'Client net stats: %Lu bytes sent, %Lu bytes received, %Lu msec elapsed' (ignored)
03/24/2016 11:46 AMPosted by Store
Could anyone with a working connection open 2 terminals, in the first run
nc -l -p 1119 | xxd
And in the second terminal run:
gnutls-cli -V -d 9999 -p 1119 --priority 'NORMAL:-VERS-SSL3.0:-VERS-SSL3.0:-VERS-SSL3.0' localhost


From my working system:

0x16, 0x03

M.
to update to 15.10 had to reset my administrator password. updated from cd fresh install deleted everything.

updated to 15.10

wine version 1.9.6

kernel version 4.2.0-34 generic

can confirm this as a fix! thanks guys pass along the good news xD
03/24/2016 01:02 PMPosted by Ötzi
to update to 15.10 had to reset my administrator password. updated from cd fresh install deleted everything.

updated to 15.10

wine version 1.9.2

kernel version 4.2.0-34 generic

can confirm this as a fix! thanks guys pass along the good news xD


i am upgrading ubuntu to 15.10 right now, windows 10 is unbearable after using ubuntu for so long.

does the wine version matter? i have been using wine 1.9.6 but on ubuntu 14.04
03/24/2016 01:08 PMPosted by Castoreum
03/24/2016 01:02 PMPosted by Ötzi
to update to 15.10 had to reset my administrator password. updated from cd fresh install deleted everything.

updated to 15.10

wine version 1.9.2

kernel version 4.2.0-34 generic

can confirm this as a fix! thanks guys pass along the good news xD


i am upgrading ubuntu to 15.10 right now, windows 10 is unbearable after using ubuntu for so long.

does the wine version matter? i have been using wine 1.9.6 but on ubuntu 14.04

according to posts I’ve read in multiple threads using 1.9.6 is the only one. seen people get issues on Ubuntu 15.10 with different wine version then update to 1.9.6 and it fix the problem
03/24/2016 01:16 PMPosted by Ötzi
03/24/2016 01:08 PMPosted by Castoreum
...

i am upgrading ubuntu to 15.10 right now, windows 10 is unbearable after using ubuntu for so long.

does the wine version matter? i have been using wine 1.9.6 but on ubuntu 14.04

according to posts I’ve read in multiple threads using 1.9.6 is the only one. seen people get issues on Ubuntu 15.10 with different wine version then update to 1.9.6 and it fix the problem


i saw that you were using wine 1.9.2 i was just wondering if that made it work for you instead of 1.9.6
03/24/2016 01:23 PMPosted by Castoreum
03/24/2016 01:16 PMPosted by Ötzi
...
according to posts I’ve read in multiple threads using 1.9.6 is the only one. seen people get issues on Ubuntu 15.10 with different wine version then update to 1.9.6 and it fix the problem


i saw that you were using wine 1.9.2 i was just wondering if that made it work for you instead of 1.9.6


ahhh so sorry i meant 1.9.6! i just changed it xD
03/24/2016 01:02 PMPosted by Ötzi

can confirm this as a fix! thanks guys pass along the good news xD


Glad to hear it's working for you now. :)
Whee, managed to get back into the forums!

So, I can confirm that on my non-working installation gnutls was offering SSLv3 by default (160300). I got the newest 3.3 version from gnutls.org and compiled it (3.4 won't compile on Debian Jessie because nettle is too old).

Now gnutls offers TLS 1.0 (160301) by default, but alas, I'm still stuck at "connecting". Already tried purging and re-installing wine, so it seems something else is still amiss.

Current config
wine: 1.9.6 (32-bit)
kernel: 4.3.0-0.bpo.1-amd64
OS: Debian 8.3 (64-bit)
gnutls: 3.3.22
1 Wine 1.9.6
2 Linux THX_1138 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) i686 GNU/Linux
3 Debian Jessie
4 32-bit
5 infinite "Connecting"
6 upgraded wine, ran the gnutls test
7 no DLL overrides
8 no authenticator

gnutls-cli test returns:

0000000: 1603 0001
I'm pretty convinced the issue is caused by wine permitting SSL3.0 in the current version:

http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/secur32/schannel_gnutls.c#l143

It makes sense for Blizz to disable SSL3.0 with their auth updates on Tuesday. I guess they're just dropping those connections at the server, since they control what protocols the client uses in the normal (Windows) case. Wine may ignore any such flags and send its more permissive default. Blizz's servers expect never to see SSL3.0, and may consider seeing that old protocol as something downgrading the connection between client and server.

Very new versions of gnutls apparently ignore SSL3.0 as a permitted protocol, or at least not advertise/package it in such a way that Blizzard's servers notice.

I looked everywhere for a way to shove a different gnutls ciphersuite into wine, to no avail. We probably need a wine patch to disable SSL3.0 (or to make an option to do so) for WoW to work with older gnutls libs.
Hey fellow sufferers. Thought I'd update just to throw some more data into the mix.

Upgraded kernel from 3.19.42 to 4.3.3, 64-bit
Wine and WINEPREFIX are 64-bit, version 1.9.6 devel from WineHQ

Still stuck on connecting. :( May the WineHQ Gods send us manna from heaven soon...
So the solution to issue #2 is get rid of our old ()|ss Ubuntu distros (don't hold me to this, I haven't finished upgrading, on Windows 10 atm, so depressing). Thank you, I really did need a kick in the butt to actually do this. Going Debian - Jessy this time. :)

Timing kinda sucks though. :P

Installing Jessy now, wish me luck :)
@Serensis, that's what I thought. I haven't managed to disable sslv3 in WINE yet. I thought I could set FALSE, TRUE for sslv3 in dlls/secur32/schannel.c but that didn't fix the issue.

I am not a programmer, I just work in the same building as some.

I suspect this wasn't something the blizzard devs did, but their sysadmins did when upgrading to the new infrastructure. The new on-system libraries like openssl used by the blizzard code would have had sslv3 disabled.
03/24/2016 03:06 PMPosted by Nightness
Going Debian - Jessy this time. :)


Just a head's up - the problem does exist in Jessie. While it's by far not as bad as it used to be, Debian stable is still kind of "old".

Join the Conversation

Return to Forum