[Bug 46704] New: League Of Legends 9.4, Connection issue - We' re unable to log you in because you may be offline.
https://bugs.winehq.org/show_bug.cgi?id=46704
Bug ID: 46704 Summary: League Of Legends 9.4, Connection issue - We're unable to log you in because you may be offline. Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: werifGX@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 63664 --> https://bugs.winehq.org/attachment.cgi?id=63664 Screenshot of the issue.
League Of Legends (9.4-15540347.15540320) is unable to log-in on wine-4.2 (Staging) with vcrun2017, adobeair and corefonts due "We're unable to log you in because you may be offline" error
Same problem on Lutris's League Of Legends (https://lutris.net/games/install/3552/view)
Both of which worked without any noticable issues yesterday (22.02.2019).
Results in : https://i.imgur.com/wIJ4Zit.png
https://bugs.winehq.org/show_bug.cgi?id=46704
Enol P. enolp@softastur.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |enolp@softastur.org
--- Comment #1 from Enol P. enolp@softastur.org --- Same problem here since last LoL patch. Also, the game keeps repairing itself every time is launched but only once, then the "We're unable to log you in because you may be offline." message appears and I cannot log in because input boxes are grayed out. Tested on Wine Staging 4.0, 4.1 and 4.2.
https://bugs.winehq.org/show_bug.cgi?id=46704
pattietreutel katyaberezyaka@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katyaberezyaka@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46704
Remy remy@adriaanse.it changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |remy@adriaanse.it
--- Comment #2 from Remy remy@adriaanse.it --- Same issue here as well, playing in EUW region. Check attached log, which is a full install from scratch up until the client login where the error is shown.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #3 from Remy remy@adriaanse.it --- Created attachment 63682 --> https://bugs.winehq.org/attachment.cgi?id=63682 Log of clean, full install up until client login screen
https://bugs.winehq.org/show_bug.cgi?id=46704
claudio.luethi@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |claudio.luethi@gmx.net
--- Comment #4 from claudio.luethi@gmx.net --- I have the Same issue using Lutris with Wine version tgk-4.2x86_64. It worked the day before a new patch was applied. Reinstalling didnt help solving the issue.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #5 from Remy remy@adriaanse.it --- Somehow after (again) switching to 'tgk-4.2x86_64' it started working all of the sudden. Client starts with something like "We've rolled back an older version..." but now login isn't grayed-out anymore. After login client will start downloading patches (left corner) and I can play just fine.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- I can't reproduce this at all with plain Staging 4.2. Has anyone managed to reproduce this without using Lutris? If not, I suspect one of their additional patches is to blame.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #7 from Jacob Hrbek werifGX@gmail.com --- (In reply to Zebediah Figura from comment #6)
I can't reproduce this at all with plain Staging 4.2. Has anyone managed to reproduce this without using Lutris? If not, I suspect one of their additional patches is to blame.
Same issue on my side using wine-4.2 (Staging) from https://dl.winehq.org/wine-builds/debian/ with these installed packages http://ix.io/1BXR on ubuntu 18.10 with custom wineprefix without any but default deps -> Won't download.
If relevant tried plain wine from lutris 3.18-staging and 3.17-staging (deps: vcrun2017 corefonts winxp) assuming you assume issue with tkg. -> 3.18-staging allows game to download, but hangs on login screen. - Game is sometimes able to download on default lutris configuration using tkg-wine-4.2 reproducable 1 of 6 times and is downloading in login screen and seems to work, but after it's stopped it results in bugsplat fatal err and if invoked again error "We have restored this installation to older.." appears and issue is present again https://i.imgur.com/2MnV27u.png.
Will try to reproduce on gentoo once i fix it, eta +- 0.1~2 days.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #8 from claudio.luethi@gmx.net --- I Did some Testing and actualy switched to a other Wine version (tgk-4.2x86_64) on lutris and it worked. Is told me something that the launcher will be set back to a older version and then it updated and the offline-bug was gone. But after Restarting the whole Launcher the bug was back.
I tried it with Snap-Lol and exactly the same happened. The launcher told me im offline but after 3 restarts it told me that the launcher will roll back and then i was able to log in and it was upgrading.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- It seems that only users from Debian-based ecosystems are affected. It would seem prudent to check apt update logs to see what changes may have occurred in dependent libraries.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Zebediah Figura from comment #9)
It seems that only users from Debian-based ecosystems are affected. It would seem prudent to check apt update logs to see what changes may have occurred in dependent libraries.
A user has provided me with a log off-line, and based on the date and being limited to Debian-based distributions I'm willing to bet the culprit is an update to bind9 (and libisc*, liblwres, libdns, etc.)
Can someone affected try downgrading or otherwise bypassing bind9?
https://bugs.winehq.org/show_bug.cgi?id=46704
Jonathan Preston jpreston@jpreston.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jpreston@jpreston.net
--- Comment #11 from Jonathan Preston jpreston@jpreston.net --- (In reply to Zebediah Figura from comment #10)
(In reply to Zebediah Figura from comment #9)
It seems that only users from Debian-based ecosystems are affected. It would seem prudent to check apt update logs to see what changes may have occurred in dependent libraries.
A user has provided me with a log off-line, and based on the date and being limited to Debian-based distributions I'm willing to bet the culprit is an update to bind9 (and libisc*, liblwres, libdns, etc.)
Can someone affected try downgrading or otherwise bypassing bind9?
Thanks for the suggestion, but I'm not sure that this is the issue.
For reference, I am running Ubuntu 18.04.2, and loading League through Lutris. I have tested against tkg and non-tkg versions of Wine, including 4.2 staging. League will launch in perhaps 10% of attempts.
My last successful game happened very early on 2019-02-23 (just after midnight), running tkg-4.0. By late-day 02-23, League was non-functional under the same Wine build. My apt logs show that the bind9 packages were updated in between that time from 1:9.11.3+dfsg-1ubuntu1.3 to 1:9.11.3+dfsg-1ubuntu1.5.
I reverted all the bind9 packages with the following command (sorry if pasting this here is too much -- seemed too short for an attachment):
aptitude install \ libdns-export1100=1:9.11.3+dfsg-1ubuntu1 \ libisc-export169=1:9.11.3+dfsg-1ubuntu1 \ libirs160=1:9.11.3+dfsg-1ubuntu1 \ dnsutils=1:9.11.3+dfsg-1ubuntu1 \ bind9-host=1:9.11.3+dfsg-1ubuntu1 \ libbind9-160=1:9.11.3+dfsg-1ubuntu1 \ libisccfg160=1:9.11.3+dfsg-1ubuntu1 \ libisccc160=1:9.11.3+dfsg-1ubuntu1 \ libdns1100=1:9.11.3+dfsg-1ubuntu1 \ libisc169=1:9.11.3+dfsg-1ubuntu1 \ liblwres160=1:9.11.3+dfsg-1ubuntu1
No additional dependency issues were noted by aptitude, and no other packages looked particularly relevant to network problems. I then rebooted the system (just to make sure all services got a restart).
This does not appear to have resolved the issue. I still see the same problems.
This appears to be correlated with the launch of a new patch in League. My suspicion is that they introduced code that relies on an API which Wine doesn't appropriately support yet.
Can I do anything else to help? Would error logs be helpful?
https://bugs.winehq.org/show_bug.cgi?id=46704
Sazmap0@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Sazmap0@gmail.com
--- Comment #12 from Sazmap0@gmail.com --- Created attachment 63694 --> https://bugs.winehq.org/attachment.cgi?id=63694 List of apt packages installed on Ubuntu 18.04 system that is working
Created on an Ubuntu 18.04 system that has not had package updates since 2019-02-07.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #13 from Sazmap0@gmail.com --- (In reply to Jonathan Preston from comment #11)
(In reply to Zebediah Figura from comment #10)
(In reply to Zebediah Figura from comment #9)
It seems that only users from Debian-based ecosystems are affected. It would seem prudent to check apt update logs to see what changes may have occurred in dependent libraries.
A user has provided me with a log off-line, and based on the date and being limited to Debian-based distributions I'm willing to bet the culprit is an update to bind9 (and libisc*, liblwres, libdns, etc.)
Can someone affected try downgrading or otherwise bypassing bind9?
Thanks for the suggestion, but I'm not sure that this is the issue.
For reference, I am running Ubuntu 18.04.2, and loading League through Lutris. I have tested against tkg and non-tkg versions of Wine, including 4.2 staging. League will launch in perhaps 10% of attempts.
My last successful game happened very early on 2019-02-23 (just after midnight), running tkg-4.0. By late-day 02-23, League was non-functional under the same Wine build. My apt logs show that the bind9 packages were updated in between that time from 1:9.11.3+dfsg-1ubuntu1.3 to 1:9.11.3+dfsg-1ubuntu1.5.
I reverted all the bind9 packages with the following command (sorry if pasting this here is too much -- seemed too short for an attachment):
aptitude install \ libdns-export1100=1:9.11.3+dfsg-1ubuntu1 \ libisc-export169=1:9.11.3+dfsg-1ubuntu1 \ libirs160=1:9.11.3+dfsg-1ubuntu1 \ dnsutils=1:9.11.3+dfsg-1ubuntu1 \ bind9-host=1:9.11.3+dfsg-1ubuntu1 \ libbind9-160=1:9.11.3+dfsg-1ubuntu1 \ libisccfg160=1:9.11.3+dfsg-1ubuntu1 \ libisccc160=1:9.11.3+dfsg-1ubuntu1 \ libdns1100=1:9.11.3+dfsg-1ubuntu1 \ libisc169=1:9.11.3+dfsg-1ubuntu1 \ liblwres160=1:9.11.3+dfsg-1ubuntu1
No additional dependency issues were noted by aptitude, and no other packages looked particularly relevant to network problems. I then rebooted the system (just to make sure all services got a restart).
This does not appear to have resolved the issue. I still see the same problems.
This appears to be correlated with the launch of a new patch in League. My suspicion is that they introduced code that relies on an API which Wine doesn't appropriately support yet.
Can I do anything else to help? Would error logs be helpful?
See above. I have a system that I don't boot often that League seems to work fine on. The login screen comes through 10/10 times, and no issues at all with the 'Appear to be offline' message.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #14 from Sazmap0@gmail.com --- (In reply to Jonathan Preston from comment #11)
(In reply to Zebediah Figura from comment #10)
(In reply to Zebediah Figura from comment #9)
It seems that only users from Debian-based ecosystems are affected. It would seem prudent to check apt update logs to see what changes may have occurred in dependent libraries.
A user has provided me with a log off-line, and based on the date and being limited to Debian-based distributions I'm willing to bet the culprit is an update to bind9 (and libisc*, liblwres, libdns, etc.)
Can someone affected try downgrading or otherwise bypassing bind9?
Thanks for the suggestion, but I'm not sure that this is the issue.
For reference, I am running Ubuntu 18.04.2, and loading League through Lutris. I have tested against tkg and non-tkg versions of Wine, including 4.2 staging. League will launch in perhaps 10% of attempts.
My last successful game happened very early on 2019-02-23 (just after midnight), running tkg-4.0. By late-day 02-23, League was non-functional under the same Wine build. My apt logs show that the bind9 packages were updated in between that time from 1:9.11.3+dfsg-1ubuntu1.3 to 1:9.11.3+dfsg-1ubuntu1.5.
I reverted all the bind9 packages with the following command (sorry if pasting this here is too much -- seemed too short for an attachment):
aptitude install \ libdns-export1100=1:9.11.3+dfsg-1ubuntu1 \ libisc-export169=1:9.11.3+dfsg-1ubuntu1 \ libirs160=1:9.11.3+dfsg-1ubuntu1 \ dnsutils=1:9.11.3+dfsg-1ubuntu1 \ bind9-host=1:9.11.3+dfsg-1ubuntu1 \ libbind9-160=1:9.11.3+dfsg-1ubuntu1 \ libisccfg160=1:9.11.3+dfsg-1ubuntu1 \ libisccc160=1:9.11.3+dfsg-1ubuntu1 \ libdns1100=1:9.11.3+dfsg-1ubuntu1 \ libisc169=1:9.11.3+dfsg-1ubuntu1 \ liblwres160=1:9.11.3+dfsg-1ubuntu1
No additional dependency issues were noted by aptitude, and no other packages looked particularly relevant to network problems. I then rebooted the system (just to make sure all services got a restart).
This does not appear to have resolved the issue. I still see the same problems.
This appears to be correlated with the launch of a new patch in League. My suspicion is that they introduced code that relies on an API which Wine doesn't appropriately support yet.
Can I do anything else to help? Would error logs be helpful?
Can you provide a list of all packages that were installed between League working and not working? So that I can try and use ALL files(non-destructively, I'll copy them off my other system) updated and we can work from there
https://bugs.winehq.org/show_bug.cgi?id=46704
draethynb@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |draethynb@gmail.com
--- Comment #15 from draethynb@gmail.com --- Created attachment 63697 --> https://bugs.winehq.org/attachment.cgi?id=63697 apt-history.log of 2-22-19 to present
This is a list of my apt-history.log from 2-22-19 to present. Of note, dnsutils and 3 libdns packages were updated.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #16 from Jonathan Preston jpreston@jpreston.net --- Created attachment 63704 --> https://bugs.winehq.org/attachment.cgi?id=63704 jpreston apt update list from 2019-02-22 through 2019-02-23
Sazmap0,
Here's my /var/log/apt/history.log from the dates in question. Please note that my last successful game was early in the morning of the 23rd. Also note that the package updates late-day on the 23rd were done after League was broken.
Based on a comparison to your working system package list, I reverted Bind9, and also GhostScript, to the base for the distribution...
aptitude install \ libdns-export1100=1:9.11.3+dfsg-1ubuntu1 \ libisc-export169=1:9.11.3+dfsg-1ubuntu1 \ libirs160=1:9.11.3+dfsg-1ubuntu1 \ dnsutils=1:9.11.3+dfsg-1ubuntu1 \ bind9-host=1:9.11.3+dfsg-1ubuntu1 \ libbind9-160=1:9.11.3+dfsg-1ubuntu1 \ libisccfg160=1:9.11.3+dfsg-1ubuntu1 \ libisccc160=1:9.11.3+dfsg-1ubuntu1 \ libdns1100=1:9.11.3+dfsg-1ubuntu1 \ libisc169=1:9.11.3+dfsg-1ubuntu1 \ liblwres160=1:9.11.3+dfsg-1ubuntu1 \ libgs9=9.22~dfsg+1-0ubuntu1 \ libgs9-common=9.22~dfsg+1-0ubuntu1 \ ghostscript=9.22~dfsg+1-0ubuntu1 \ ghostscript-x=9.22~dfsg+1-0ubuntu1
This still didn't fix the problem. The only package I can see different that I didn't try to revert is grub-pc-bin, because I can't imagine why Grub would be connected to this issue.
https://bugs.winehq.org/show_bug.cgi?id=46704
Farcrada farcrada@yandex.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |farcrada@yandex.com
--- Comment #17 from Farcrada farcrada@yandex.com --- (In reply to Sazmap0 from comment #12)
Created attachment 63694 [details] List of apt packages installed on Ubuntu 18.04 system that is working
Created on an Ubuntu 18.04 system that has not had package updates since 2019-02-07.
I have the same updates as Jonathan Preston on Linux Mint 19.1 received at: 2019-02-22@16:00-UTC+1.
I made a Reddit post regarding this (https://reddit.com/r/wine_gaming/comments/auzbe3/) and was aptly referred here by Zebediah.
For those looking for a way to compare lists against Sazmap0's list, I made a nice utility program in Python 3 that attempts to do just this. You can dump the results to a file and then attach it here to help with troubleshooting. Link: https://github.com/Farcrada/AptListComparer
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #18 from Sazmap0@gmail.com --- (In reply to Jonathan Preston from comment #16)
Created attachment 63704 [details] jpreston apt update list from 2019-02-22 through 2019-02-23
Sazmap0,
Here's my /var/log/apt/history.log from the dates in question. Please note that my last successful game was early in the morning of the 23rd. Also note that the package updates late-day on the 23rd were done after League was broken.
Based on a comparison to your working system package list, I reverted Bind9, and also GhostScript, to the base for the distribution...
<snip>
This still didn't fix the problem. The only package I can see different that I didn't try to revert is grub-pc-bin, because I can't imagine why Grub would be connected to this issue.
I did a bit of text processing and came up with the following list of packages that were updated (seems to be _slightly_ different from the list that you used). I would agree that the grub is probably irrelevant.
Seems that other than grub, the only other differences are libcogl* and the pci stuff. I can't imagine either of those would have impact, but I guess it's worth a try?
It's also possible that the config has changed for one of the libraries that doesn't get reverted when downgrading.
bind9-host 1:9.11.3+dfsg-1ubuntu1.3 dnsutils 1:9.11.3+dfsg-1ubuntu1.3 ghostscript 9.26~dfsg+0-0ubuntu0.18.04.4 ghostscript-x 9.26~dfsg+0-0ubuntu0.18.04.4 grub-pc-bin 2.02-2ubuntu8.10 libbind9-160 1:9.11.3+dfsg-1ubuntu1.3 libcec4 4.0.2+dfsg1-2ubuntu1 libcogl20 1.22.2-3 libcogl-common 1.22.2-3 libcogl-pango20 1.22.2-3 libcogl-path20 1.22.2-3 libdns1100 1:9.11.3+dfsg-1ubuntu1.3 libdns-export1100 1:9.11.3+dfsg-1ubuntu1.3 libgs9 9.26~dfsg+0-0ubuntu0.18.04.4 libgs9-common 9.26~dfsg+0-0ubuntu0.18.04.4 libirs160 1:9.11.3+dfsg-1ubuntu1.3 libisc169 1:9.11.3+dfsg-1ubuntu1.3 libisccc160 1:9.11.3+dfsg-1ubuntu1.3 libisccfg160 1:9.11.3+dfsg-1ubuntu1.3 libisc-export169 1:9.11.3+dfsg-1ubuntu1.3 liblwres160 1:9.11.3+dfsg-1ubuntu1.3 libpci3 1:3.5.2-1ubuntu1 pciutils 1:3.5.2-1ubuntu1
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #19 from Sazmap0@gmail.com --- After including the apt-history provided by draethynb, the following packages are common between the test system, and the two apt-history logs: bind9-host 1:9.11.3+dfsg-1ubuntu1.3 dnsutils 1:9.11.3+dfsg-1ubuntu1.3 ghostscript 9.26~dfsg+0-0ubuntu0.18.04.4 ghostscript-x 9.26~dfsg+0-0ubuntu0.18.04.4 libbind9-160 1:9.11.3+dfsg-1ubuntu1.3 libdns1100 1:9.11.3+dfsg-1ubuntu1.3 libdns-export1100 1:9.11.3+dfsg-1ubuntu1.3 libgs9 9.26~dfsg+0-0ubuntu0.18.04.4 libgs9-common 9.26~dfsg+0-0ubuntu0.18.04.4 libirs160 1:9.11.3+dfsg-1ubuntu1.3 libisc169 1:9.11.3+dfsg-1ubuntu1.3 libisccc160 1:9.11.3+dfsg-1ubuntu1.3 libisccfg160 1:9.11.3+dfsg-1ubuntu1.3 libisc-export169 1:9.11.3+dfsg-1ubuntu1.3 liblwres160 1:9.11.3+dfsg-1ubuntu1.3 libpci3 1:3.5.2-1ubuntu1 pciutils 1:3.5.2-1ubuntu1
Looks like the only thing that is actually different between this list and what was tested with a rollback by Jonathan Preston is libpci3 and pciutils.
It seems pretty unlikely that these packages would affect it, but probably worth testing.
Seeming more likely that there is a config file involved that has changed something.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #20 from Jacob Hrbek werifGX@gmail.com --- Created attachment 63721 --> https://bugs.winehq.org/attachment.cgi?id=63721 Riot response
Seems there wasn't any changes in league of legends that might cause this issue.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #21 from Jonathan Preston jpreston@jpreston.net --- (In reply to Sazmap0 from comment #19)
Looks like the only thing that is actually different between this list and what was tested with a rollback by Jonathan Preston is libpci3 and pciutils.
I don't think this is accurate. The manual apt upgrade I did on 2019-02-23 @ 23:23:46, in which pciutils and libcogl were upgraded, actually happened after League was not working, not before.
Seeming more likely that there is a config file involved that has changed something.
Any idea how we might narrow that down? And, if a config file changed, that might not be an error in the package, so we might still possibly be looking at a Wine bug itself, then?
https://bugs.winehq.org/show_bug.cgi?id=46704
zepar stefanfunk1998@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefanfunk1998@gmail.com
--- Comment #22 from zepar stefanfunk1998@gmail.com --- just a heads up, as it might lead to more information, there was this comment on reddit, which explained something about the league client always using 1.1.1.1 as DNS and got different responses under certain circumstances, which either let him through with the login or showed the error
i dont know what the last line, the edit, exactly means, but ill still leave this information here just in case
https://www.reddit.com/r/wine_gaming/comments/auzbe3/league_of_legends_the_l...
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #23 from Zebediah Figura z.figura12@gmail.com --- Observations from myself and others:
* The bug doesn't seem to consistently appear. I think some people have reported getting in after several tries.
* IIRC at least one person has reported the problem being fixed by switching to a certain build of Wine (that from "TKG"). However, "TKG" reported that this seems to just be a fluke based on the above.
* Only people from Debian-based distributions seem to be affected; others are not. This alone suggests that, regardless of whether there is a bug in Wine, the condition can be traced back to a recent change in the Debian ecosystem that would not have affected anyone else. From provided apt logs and dates, and the problem's apparent relevance to network code, bind9 (et al.) looks like an extremely likely culprit. Even if downgrading the library doesn't help, I'm not sure I want to rule it out just yet: there may be a difference in config files, or possibly the prefix is corrupted by one failure.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #24 from Sazmap0@gmail.com --- (In reply to Jonathan Preston from comment #21)
(In reply to Sazmap0 from comment #19)
Looks like the only thing that is actually different between this list and what was tested with a rollback by Jonathan Preston is libpci3 and pciutils.
I don't think this is accurate. The manual apt upgrade I did on 2019-02-23 @ 23:23:46, in which pciutils and libcogl were upgraded, actually happened after League was not working, not before.
Ok. It's probably something to do with the libraries that have already been tested then.
Any idea how we might narrow that down? And, if a config file changed, that might not be an error in the package, so we might still possibly be looking at a Wine bug itself, then?
I'm not at home with access to my other system until tonight (8pm ADST), but when I get home I will list all the files in all the narrowed down packages on my working and non-working systems and see what differences I can find.
https://bugs.winehq.org/show_bug.cgi?id=46704
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #25 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- It may be a shot in the dark, but I once had an issue with round-robin cycling being enabled in my local network DNS server. I had to disable it and/or forward to a non-round-robin-enabled distant DNS server. The program (PunkBuster pbsetup.exe in that case) expected the DNS resolution in a fixed order. The DNS resolve cycled between 3 IPs but the program could only connect to one. It seemed random until the cause was identified. See https://bugs.winehq.org/show_bug.cgi?id=38820#c4.
The reddit post and relation to the bind package remind me of that issue.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #26 from Jonathan Preston jpreston@jpreston.net --- Please check the comment here, where someone claims to have gotten his success rate much higher: https://www.reddit.com/r/leagueoflinux/comments/auumb8/did_anyone_get_a_fix_...
Specifically, what he did, after noticing that League sends some DNS requests directly to 1.1.1.1 (Cloudflare DNS), was redirect the traffic to 127.0.0.53:53. He now claims about a 50% success rate launching League.
Any thoughts on how this might be connected?
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #27 from Jonathan Preston jpreston@jpreston.net --- I made some progress, I think. I am now able to successfully log in in all cases, assuming the game launches to the login screen (which it doesn't about 50% of the time, but I think that's an unrelated issue).
Essentially, what I did is bypass systemd-resolved.
To reproduce the "solution" on Ubuntu 18.04 (assuming you are already impacted by this issue):
1. Tell Network Manager not to manage our resolv.conf by editing /etc/NetworkManager/NetworkManager.conf, and adding the following line to the [main] section: dns=none 2. Restart Network Manager: systemctl restart network-manager 3. Now remove symlinked resolv.conf that is part of systemd: rm /etc/resolv.conf 4. Create a new resolv.conf with your text editor of choice and add the following line: nameserver 8.8.8.8 5. Restart Network Manager again.
To revert the changes: Remove the line "dns=none" from /etc/NetworkManager/NetworkManager.conf rm /etc/resolv.conf ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf systemctl restart network-manager
I'm not exactly sure why this works, but it does work on the one system I've tried it on, and the problem returned immediately when I reverted the changes. Naturally, I do not recommend this approach as a permanent workaround, as local DNS caching is generally good.
Hopefully this is helpful information.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #28 from Hans Leidekker hans@meelstraat.net --- (In reply to Jonathan Preston from comment #27)
I made some progress, I think. I am now able to successfully log in in all cases, assuming the game launches to the login screen (which it doesn't about 50% of the time, but I think that's an unrelated issue).
Essentially, what I did is bypass systemd-resolved.
To reproduce the "solution" on Ubuntu 18.04 (assuming you are already impacted by this issue):
- Tell Network Manager not to manage our resolv.conf by editing
/etc/NetworkManager/NetworkManager.conf, and adding the following line to the [main] section: dns=none 2. Restart Network Manager: systemctl restart network-manager 3. Now remove symlinked resolv.conf that is part of systemd: rm /etc/resolv.conf 4. Create a new resolv.conf with your text editor of choice and add the following line: nameserver 8.8.8.8 5. Restart Network Manager again.
To revert the changes: Remove the line "dns=none" from /etc/NetworkManager/NetworkManager.conf rm /etc/resolv.conf ln -s /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf systemctl restart network-manager
I'm not exactly sure why this works, but it does work on the one system I've tried it on, and the problem returned immediately when I reverted the changes. Naturally, I do not recommend this approach as a permanent workaround, as local DNS caching is generally good.
Could you attach +dnsapi,+winsock traces from a good and bad run?
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #29 from Sazmap0@gmail.com ---
I'm not at home with access to my other system until tonight (8pm ADST), but when I get home I will list all the files in all the narrowed down packages on my working and non-working systems and see what differences I can find.
So I got home to find that even though I only booted the system for maybe 2 minutes, it was enough time for it to autoupdate and install the newer packages. So unfortunately my reference machine with the old-packages that works is no longer working.
I had a dig with the information I now have (not a lot unfortunately, but I exploded all the packages installed), but it seems that the packages that are updated that potentially have issues are consisting exclusively of man pages and libraries, and none of them have any pre or post install config changes that would cause the issues (I think. There are some ldconfig changes and stuff but I wouldn't imagine it would change anything).
I made some progress, I think.
<snip>
I'll give this a try and see what happens.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #30 from Sazmap0@gmail.com --- Created attachment 63738 --> https://bugs.winehq.org/attachment.cgi?id=63738 Wine Debug Log of a pass-run for League of Legends after making resolv.conf fixes
Could you attach +dnsapi,+winsock traces from a good and bad run?
This is an attachment of a run that works fine (up to login screen) after making the resolv.conf changes. I'm currently trying to get a run that fails but doesn't restart (it usually says 'we've reverted to a previous version ... ' and restarts, meaning the log is a lot larger), but if I can't, I'll just upload that log (it's almost 90MB)
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #31 from Sazmap0@gmail.com --- Created attachment 63739 --> https://bugs.winehq.org/attachment.cgi?id=63739 Wine Debug Log of a fail-run without a restart
(In reply to Sazmap0 from comment #30)
I'm currently trying to get a run that fails but doesn't restart (it usually says 'we've reverted to a previous version ... ' and restarts, meaning the log is a lot larger), but if I can't, I'll just upload that log (it's almost 90MB)
Got a run that fails and didn't prompt for a roll-back or update. Log attached.
I also got a run that failed and prompted for a roll-back, and then once the roll-back and repatch was finished, it actually worked. That log is 80MB though so I'm hesitant to upload it.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #32 from Sazmap0@gmail.com --- (In reply to Sazmap0 from comment #31)
I also got a run that failed and prompted for a roll-back, and then once the roll-back and repatch was finished, it actually worked. That log is 80MB though so I'm hesitant to upload it.
Okay so just for completeness I uploaded two more logs:
This one is a Fail -> rollback -> patch -> fail log: https://send.firefox.com/download/4bf473edf4/#ZC_UTSwyqtTfBIZhuDKeRQ
And this one is a Fail -> rollback -> patch -> success log: https://send.firefox.com/download/3fd21f7fbf/#oGHsYaG6Gpio4IP6kPvjTA
Hopefully all these logs provide enough information to work out exactly what is going on!
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #33 from Sazmap0@gmail.com --- (In reply to Jonathan Preston from comment #27)
I made some progress, I think. I am now able to successfully log in in all cases, assuming the game launches to the login screen (which it doesn't about 50% of the time, but I think that's an unrelated issue).
Essentially, what I did is bypass systemd-resolved.
<snip>
Hopefully this is helpful information.
Sorry, didn't make it clear in my previous replies - I have tried this and can confirm it 'solves' the problem (can login, do not get the repatch loop)
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #34 from Hans Leidekker hans@meelstraat.net --- Good run:
0066:trace:winsock:WS_getaddrinfo "auth.riotgames.com", "443" 0x48cf518 -> 0xad0fe50 0 0066:trace:winsock:WS_inet_ntop family 2, addr (0x490a0a4), buffer (0xad0fdde), len 16 0066:trace:winsock:WS_getaddrinfo => 0x48dfd50, flags 0, family 2, type 1, protocol 0, len 16, name (null), addr { family AF_INET, address 104.16.120.50, port 443 } 0066:trace:winsock:WS_inet_ntop family 2, addr (0x490a0e4), buffer (0xad0fdde), len 16 0066:trace:winsock:WS_getaddrinfo => 0x490a0b8, flags 0, family 2, type 1, protocol 0, len 16, name (null), addr { family AF_INET, address 104.16.119.50, port 443 }
Bad run:
0066:trace:winsock:WS_getaddrinfo "auth.riotgames.com", "443" 0x48cfcc8 -> 0xad0fe50 0 0066:trace:winsock:WS_inet_ntop family 2, addr (0x48e1a54), buffer (0xad0fdde), len 16 0066:trace:winsock:WS_getaddrinfo => 0x48f2640, flags 0, family 2, type 1, protocol 0, len 16, name (null), addr { family AF_INET, address 104.16.119.50, port 443 } 0066:trace:winsock:WS_inet_ntop family 2, addr (0x48f0d0c), buffer (0xad0fdde), len 16 0066:trace:winsock:WS_getaddrinfo => 0x48f2820, flags 0, family 2, type 1, protocol 0, len 16, name (null), addr { family AF_INET, address 104.16.120.50, port 443 }
So the 2 addresses are returned in different order. You'd need to do some more runs to see if one of these consistently fails. If I look up the hostname manually on Debian 9 (dig auth.riotgames.com) I get a seemingly random order of the A records. On Windows the order is strictly reversed every time I look it up (nslookup auth.riotgames.com).
Another interesting bit is that the TTL for auth.riotgames.com (CNAME record for auth.riotgames.com.cdn.cloudflare.com) is dynamic. The 2 A records also have a dynamic TTL. The A record TTL values are always the same, but different from the CNAME TTL.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #35 from Farcrada farcrada@yandex.com --- Created attachment 63740 --> https://bugs.winehq.org/attachment.cgi?id=63740 League hangs before Splashscreen is even loaded
(In reply to Jonathan Preston from comment #27)
I made some progress, I think. I am now able to successfully log in in all cases, assuming the game launches to the login screen (which it doesn't about 50% of the time, but I think that's an unrelated issue).
Essentially, what I did is bypass systemd-resolved.
<SNIP>
Hopefully this is helpful information.
I didn't feel like using Google's DNS nor changing loads of network stuff so I figured: If changing systemd-resolved is the issue, does using WireGuard (wg-quick up <insertVPN>) fix it? Apparently it does. It seems to resolve this issue consistently. I can even log in normally without issue. The only issue I run into now is that after it installs the first time and you close it after it won't boot at all (splash screen's just stuck).
000001.327| WARN| rcp-be-lol-lobby| Can't check registration status, not connected 000006.612| ALWAYS| Plugin Manager| Initializing plugin rcp-be-lol-account-verification: 1.0.8 000011.413| OKAY| rcp-be-lol-lobby| Set ready retry backoff time: 10.000000
This last line just repeats every 10 seconds until you kill LeagueClient.exe via system monitor. Even closing from Lutris doesn't always work. I will attach the log to the attachments. I wonder if it's stuck on account-verification or something else.
Maybe it isn't as sure fire as I thought. Though instead of just getting an empty launcher screen that's supposed to download the client, I could consistently download the 1.5GB each time, log in (and probably play) and message friends. So the connection is solid, given that I don't exit.
In other words this means that whatever WireGuard does to systemd-resolved (and it's config) fixes what WINE either can't or doesn't for League, but for me another issue arises, anyone else care to try?
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #36 from Hans Leidekker hans@meelstraat.net --- (In reply to Sazmap0 from comment #32)
This one is a Fail -> rollback -> patch -> fail log: https://send.firefox.com/download/4bf473edf4/#ZC_UTSwyqtTfBIZhuDKeRQ
And this one is a Fail -> rollback -> patch -> success log: https://send.firefox.com/download/3fd21f7fbf/#oGHsYaG6Gpio4IP6kPvjTA
Hopefully all these logs provide enough information to work out exactly what is going on!
Thanks, that rules out auth.riotgames.com address order. This might be relevant though:
01a8:trace:winsock:WSAStringToAddressA ("1.1.1.1", 2, (nil), 0xae1f810, 0xae1f7ac) 01a8:trace:winsock:WSAStringToAddressA ("8.8.8.8", 2, (nil), 0xae1f810, 0xae1f7ac) 01a8:trace:winsock:WSAStringToAddressA ("208.67.222.222", 2, (nil), 0xae1f810, 0xae1f7ac) 01a8:trace:dnsapi:DnsQuery_W (L"lol.secure.dyn.riotcdn.net",DNS_TYPE_A,0x00000100,0x4968f28,0xae1f7d4,(nil)) 01a8:trace:dnsapi:DnsQuery_UTF8 ("lol.secure.dyn.riotcdn.net",DNS_TYPE_A,0x00000100,0x4968f28,0xae1f738,(nil)) 01a8:fixme:dnsapi:dns_map_options option DNS_QUERY_WIRE_ONLY not implemented 01a8:trace:dnsapi:dns_copy_record found DNS_TYPE_CNAME record in Answer section 01a8:trace:dnsapi:dns_copy_record found DNS_TYPE_CNAME record in Answer section 01a8:trace:dnsapi:dns_copy_record found DNS_TYPE_A record in Answer section 01a8:fixme:dnsapi:dns_copy_rdata unhandled type: DNS_TYPE_OPT 01a8:trace:dnsapi:DnsRecordListFree (0x4934228,1)
The game uses dnsapi to resolve A records for lol.secure.dyn.riotcdn.net. It passes an array of nameservers to be used and it gets a reply which includes an OPT type record, which we don't handle.
If I manually perform this query against the the 3 nameservers I don't get an answer that includes an OPT record. It's not clear why you do get them.
I'll attach a patch that adds support for this record type.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #37 from Hans Leidekker hans@meelstraat.net --- Created attachment 63742 --> https://bugs.winehq.org/attachment.cgi?id=63742 patch
Does this make a difference? If it still fails, please get a +winsock,+dnsapi trace with the patch applied.
https://bugs.winehq.org/show_bug.cgi?id=46704
sebastiaandingemans@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastiaandingemans@gmail.c | |om
https://bugs.winehq.org/show_bug.cgi?id=46704
atbjyk akihiroyamaguchi1208@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |akihiroyamaguchi1208@gmail. | |com
--- Comment #38 from atbjyk akihiroyamaguchi1208@gmail.com --- thanks!! It looks like it worked.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #39 from Jonathan Preston jpreston@jpreston.net --- Sadly, I haven't been able to test this patch as of yet, because building Wine in Ubuntu seems to be a bit of a nightmare (even with the guides on doing so from the Wiki). If needed, I can try to put a few hours into this over the weekend, but I'm not really experienced in building something as complex as Wine.
Specifically, apt build-dep seems not to be getting all the needed dependencies, so I tried to add them all by hand. Unfortunately make still fails (unknown type names from one of the dependencies, I'm guessing). I did all of this in a VM, and I did successfully apply the patch, along with Wine-staging to the 4.2 sources, so if someone wanted to give me a detailed how-to on going from clean Ubuntu 18.04 to compiling Wine, I'd be willing to try again to build this.
On the other hand, if someone else can test this patch more easily than I, that would be fantastic.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #40 from Sazmap0@gmail.com --- (In reply to Jonathan Preston from comment #39)
so if someone wanted to give me a detailed how-to on going from clean Ubuntu 18.04 to compiling Wine, I'd be willing to try again to build this.
On the other hand, if someone else can test this patch more easily than I, that would be fantastic.
I'm currently building wine using the PKGBUILDS stuff and docker (https://github.com/Tk-Glitch/PKGBUILDS/issues/69). Hopefully this will all work fine, and I should be able to test this tomorrow (I'll leave it compiling tonight while I'm out)
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #41 from Farcrada farcrada@yandex.com --- (In reply to Farcrada from comment #35)
Created attachment 63740 [details] League hangs before Splashscreen is even loaded
(In reply to Jonathan Preston from comment #27)
I made some progress, I think. I am now able to successfully log in in all cases, assuming the game launches to the login screen (which it doesn't about 50% of the time, but I think that's an unrelated issue).
Essentially, what I did is bypass systemd-resolved.
<SNIP>
Hopefully this is helpful information.
I didn't feel like using Google's DNS nor changing loads of network stuff so I figured: If changing systemd-resolved is the issue, does using WireGuard (wg-quick up <insertVPN>) fix it? Apparently it does. It seems to resolve this issue consistently. I can even log in normally without issue. The only issue I run into now is that after it installs the first time and you close it after it won't boot at all (splash screen's just stuck).
<SNIP>
In other words this means that whatever WireGuard does to systemd-resolved (and it's config) fixes what WINE either can't or doesn't for League, but for me another issue arises, anyone else care to try?
Well.. I'm proud to announce this was a me issue: I figured I’d retry and fiddle with the Lutris settings, well… Whaddaya know, I found a way to bring back the screen. Right click League in Lutris -> Configure -> System Options -> Adjust below values like so: Disable Lutris Runtime = true Prefer system libraries = false
I consistently log in and update the launcher/client/game now.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #42 from Sazmap0@gmail.com --- (In reply to Hans Leidekker from comment #37)
Created attachment 63742 [details] patch
Does this make a difference? If it still fails, please get a +winsock,+dnsapi trace with the patch applied.
Preliminary tests (only started the game twice, I'm a bit busy today) would indicate it's working!
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #43 from Hans Leidekker hans@meelstraat.net --- (In reply to Sazmap0 from comment #42)
(In reply to Hans Leidekker from comment #37)
Created attachment 63742 [details] patch
Does this make a difference? If it still fails, please get a +winsock,+dnsapi trace with the patch applied.
Preliminary tests (only started the game twice, I'm a bit busy today) would indicate it's working!
Thanks for testing! The fix is in Wine 4.3.
https://bugs.winehq.org/show_bug.cgi?id=46704
--- Comment #44 from Jonathan Preston jpreston@jpreston.net --- I have tested Wine 4.3 (as a Lutris runner). I can confirm it fixes the DNS issue and allows consistent login.
However, while this does fix the login problem, it doesn't allow us to actually start a game. After Champion Selection, the game itself crashes, returning us to the League Client. It looks like we need one or more patches that are still in Wine-Staging.
Any idea when a Staging 4.3 package will make its way to the WineHQ repositories? (Preferably for Ubuntu 18.04 and newer releases.)
Either way, thank you for your work on this issue!
https://bugs.winehq.org/show_bug.cgi?id=46704
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Fixed by SHA1| |ecaeaa974ce93fe0c51cf063a08 | |28831a2be3dcc
--- Comment #45 from Hans Leidekker hans@meelstraat.net --- Fixed by ecaeaa974ce93fe0c51cf063a0828831a2be3dcc.
https://bugs.winehq.org/show_bug.cgi?id=46704
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #46 from Alistair Leslie-Hughes leslie_alistair@hotmail.com --- Closing Fixed Staging bugs.
-
wine-bugs＠winehq.org