Networking issues with wine-tkg-git via proton

[kkartaltepe]

Im not sure if this related to proton-tkg-git or how the prefix is setup by steam, but when trying to run some games with proton-tkg-git they were having connectivity issues. However the issue only appears under proton, running with wine directly things are working. Examples here use VRChat ID's and addresses since that's where i first noticed it but the same thing happens with www.google.com etc. Built on Archlinux from the PKGBUILD.

e.g. wine /downloads/curl-7.72.0-win64-mingw/bin/curl.exe api.vrchat.cloud resolves the host and pulls data. http://paste.debian.net/1165922/ for a log of the output.

protontricks -c "wine /downloads/curl-7.72.0-win64-mingw/bin/curl.exe api.vrchat.cloud" 438100 Fails to resolve the address. http://paste.debian.net/hidden/24d671e8/

[imaami]

Getting this as well. I did a non-makepkg build from master in a Debian unstable Docker container, and Squad can't resolve addresses.

[Tk-Glitch]

I was unable to reproduce the issue on the 5.18.r3 based release, so it seems to be a very recent regression. I'm locked with a dualcore broadwell laptop, so if someone feels like bisecting, it would save me quite a bit of time. I'll start working on it nonetheless but it might take a while :frog:

[imaami]

I'm building on top of 5.18.r3 now, will report back.

[Tk-Glitch]

Actually, I can't reproduce this on 5.18.r11 either, which is from yesterday. I'll rebase hotfixes against current head and test with that.

[kkartaltepe]

I was building off of head at the time. Unfortunately I deleted the repository once everything installed and one game worked. Ill try one of the tagged releases later today. Building takes quite some time as well so I may not be able to bisect it immediately.

[imaami]

I can't build 5.18.r3, for some reason it fails already during patching:

 -> Changing wine HEAD to the wine-staging base commit...
Note: switching to '568e3e8b697a960881c162671a33c28727921797'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 568e3e8b69 ucrtbase: Add [_]strtold[_l].
 -> Hotfixing...
error: could not revert 2a573c6f48... ws2_32: Always return WSAEINVAL if AF_UNSPEC is used with a zero protocol.

I did try running just curl with protontricks in the prefix that has this bug. I get the same errors as @kkartaltepe.

Then I did something interesting. I have wine-hq's Debian package for wine-staging 5.18 installed. It's nice because it's in /opt/wine-staging, and isn't in PATH or anything, so it can coexist without interfering. I tested what happens when I use that in Squad's prefix that was created with proton-tkg 5.18.r11 (own build).

I did:

$ export PATH="/opt/wine-staging/bin:$PATH"
$ export WINEPREFIX="/opt/steam/steamapps/compatdata/393380/pfx"
$ wine z:$(realpath curl/bin/curl.exe) -v api.vrchat.cloud

And it worked.

The funny thing is that now that same Squad prefix also works with proton-tkg 5.18.r11. I did unset the variables of course, and I've checked that Squad is actually running the wineserver from proton-tkg. But when wine-hq's vanilla wine-staging updated the prefix it changed something that made the bug go away.

I listed all the files in the prefix that seemed to get updated. The comparison is based on sha256 and timestamp:

-rwxr-xr-x 1 imaami imaami 114068 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v1.1.4322/aspnet_regiis.exe
-rw-r--r-- 1 imaami imaami 399534 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v1.1.4322/fusion.dll
-rw-r--r-- 1 imaami imaami 79211 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v1.1.4322/mscorwks.dll
-rwxr-xr-x 1 imaami imaami 114059 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v1.1.4322/ngen.exe
-rwxr-xr-x 1 imaami imaami 114062 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v1.1.4322/regsvcs.exe
-rw-r--r-- 1 imaami imaami 399534 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v2.0.50727/fusion.dll
-rw-r--r-- 1 imaami imaami 79211 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v2.0.50727/mscorwks.dll
-rwxr-xr-x 1 imaami imaami 114059 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v2.0.50727/ngen.exe
-rwxr-xr-x 1 imaami imaami 114061 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v2.0.50727/regasm.exe
-rwxr-xr-x 1 imaami imaami 114066 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v3.0/windows communication foundation/servicemodelreg.exe
-rwxr-xr-x 1 imaami imaami 111735 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v3.0/wpf/presentationfontcache.exe
-rw-r--r-- 1 imaami imaami 399534 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v4.0.30319/fusion.dll
-rwxr-xr-x 1 imaami imaami 114059 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework64/v4.0.30319/ngen.exe
-rwxr-xr-x 1 imaami imaami 93363 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v1.1.4322/aspnet_regiis.exe
-rw-r--r-- 1 imaami imaami 341636 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v1.1.4322/fusion.dll
-rw-r--r-- 1 imaami imaami 66614 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v1.1.4322/mscorwks.dll
-rwxr-xr-x 1 imaami imaami 93354 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v1.1.4322/ngen.exe
-rwxr-xr-x 1 imaami imaami 93357 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v1.1.4322/regsvcs.exe
-rw-r--r-- 1 imaami imaami 341636 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v2.0.50727/fusion.dll
-rw-r--r-- 1 imaami imaami 66614 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v2.0.50727/mscorwks.dll
-rwxr-xr-x 1 imaami imaami 93354 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v2.0.50727/ngen.exe
-rwxr-xr-x 1 imaami imaami 93356 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v2.0.50727/regasm.exe
-rwxr-xr-x 1 imaami imaami 93361 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v3.0/windows communication foundation/servicemodelreg.exe
-rwxr-xr-x 1 imaami imaami 99276 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v3.0/wpf/presentationfontcache.exe
-rw-r--r-- 1 imaami imaami 341636 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v4.0.30319/fusion.dll
-rwxr-xr-x 1 imaami imaami 93354 Oct  6 18:30 393380/pfx/drive_c/windows/Microsoft.NET/Framework/v4.0.30319/ngen.exe
-rwxr-xr-x 1 imaami imaami 1032 Oct  6 18:30 393380/pfx/drive_c/windows/system32/winemenubuilder.exe
-rwxr-xr-x 1 imaami imaami 1032 Oct  6 18:30 393380/pfx/drive_c/windows/syswow64/winemenubuilder.exe

[Tk-Glitch]

It doesn't look like you selected the correct commit for 5.18.r3. You need _staging_version="9acfa3b89931e628d7b62e843934fce26b880405" in your config. That being said it's interesting.. I did test on a clean prefix, but not on an existing one.

5.18.r3 building log, from master:

==> Starting prepare()...
  -> Changing wine HEAD to the wine-staging base commit...
Note: switching to '9a6e5b23293fbad3bbdcd52007402a3b9a1cb99d'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 9a6e5b23293 Release 5.18.
==> WARNING: HALP! We got some hotfixes for your current tree!
Do you want to apply them all with no further prompt?
> Y/n : 
  -> Hotfixing...
  -> ## Applying hotfix for wine-staging: 06877e55b1100cc49d3726e9a70f31c4dfbe66f8-99.mystagingpatch
(...)

[kkartaltepe]

Ah i see the pkgbuild tags it with the version. It looks like it built off of 5.18.r11.g19466905-299

Building from the 5.18.r3.g9acfa3b8 tag fails with:

  -> Hotfixing...
error: could not revert 2a573c6f48... ws2_32: Always return WSAEINVAL if AF_UNSPEC is used with a zero protocol.
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
==> ERROR: Patch application has failed. The error was logged to /home/kk/ceph-data/projects/wine-tkg-git/wine-tkg-git/prepare.log for your convenience.
  -> To use the last known good mainline version, please set _plain_version="9a6e5b23293fbad3bbdcd52007402a3b9a1cb99d" in your .cfg
  -> To use the last known good staging version, please set _staging_version="9acfa3b89931e628d7b62e843934fce26b880405" in your .cfg (requires _use_staging="true")

Copying the sample config and setting it to the mentioned commit starts it building but compilation eventually fails around

/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.text+0x14d0): undefined reference to `IID_IWICDdsDecoder'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xae0): undefined reference to `GUID_ContainerFormatBmp'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xae8): undefined reference to `GUID_ContainerFormatJpeg'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xaf0): undefined reference to `GUID_ContainerFormatPng'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xaf8): undefined reference to `GUID_ContainerFormatDds'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xb00): undefined reference to `GUID_ContainerFormatTiff'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xb08): undefined reference to `GUID_ContainerFormatGif'
/usr/lib/gcc/i686-w64-mingw32/10.2.0/../../../../i686-w64-mingw32/bin/ld: d3dx10_43_main.cross.o:d3dx10_43_main.c:(.rdata+0xb10): undefined reference to `GUID_ContainerFormatWmp
collect2: error: ld returned 1 exit status
...
make[1]: *** [Makefile:343: d3dx10_43.dll] Error 2
...

[Tk-Glitch]

Building from the 5.18.r3.g9acfa3b8 tag

You never want to do that. Always use master, and set _staging_version="9acfa3b89931e628d7b62e843934fce26b880405" in your config.

[imaami]

I've been able to create a build that doesn't have the bug. I replicated the config from proton-tkg-5.18.r3 and got a working build. Then I tried r5 and it had the bug.

Just speculating here because on mobile and in a hurry, but could the problem be upstream commit 9fff80d87655ae9f70094b34661abc2a399395be?

[Tk-Glitch]

That commit is already reverted in the hotfixer script. I think 6a19b999f7877f5b0052c77d09a41635769ce441 might be it, considering the "prefix tainting" behavior. Registry tainting makes more sense to me than the dotnet files. I'll push the change with the accompanying staging corrections so you guys can check that theory out. I still haven't been able to reproduce the issue on my end at this point in time btw.

[CartoonFan]

At least for me, Final Fantasy VII (which requires an internet connection) seems to be working again after your latest commit.

[imaami]

Ditto, curl also works with the latest master.

[kkartaltepe]

recompiling on head appears to fix the curl issue, protontricks appears to have rebuilt the prefix on the first run and curl succeeded.

Though as a side note now none of the games themselves are loading, I assume that is unrelated.

[imaami]

I was able to play Squad normally. @kkartaltepe try with the config from https://github.com/imaami/wine-tkg-git/tree/docker-wip, I deliberately made it as close as possible to the one in the proton-tkg-5.18.r3 release.

[kkartaltepe]

Im not sure I understand your suggestion, which configuration are you suggesting I use from your branch?

[imaami]

Im not sure I understand your suggestion, which configuration are you suggesting I use from your branch?

Oh right, sorry, was going to be more specific but got distracted...

proton-tkg/proton-tkg.cfg and proton-tkg/proton-tkg-profiles/advanced-customization.cfg.

[kkartaltepe]

It doesnt appear to have made any difference

[imaami]

It doesnt appear to have made any difference

OK, interesting. How are you rebuilding it exactly? And what happens when the games don't launch? Anything in the logs?

[kkartaltepe]

Im not sure how to extract logs from steam, attempting prototricks just triggers steam to launch the game.

As for building I am just installing with makepkg -is building wine-tkg then proton-tkg and then selecting the proton-tk compatibility stack in steam before launching.

[Tk-Glitch]

Which games? Do they have launchers? I have tested a few games with no issue on 5.19.r1, but there is a known issue (upstream regression) with some launchers such as the riot client or minecraft dungeon. 5.18.r3, however, isn't affected by that upstream regression and should be all fine.

Regarding logs, passing PROTON_LOG=1 %command% as command line parameter to your steam game (in game's properties) will create a wine log in your home folder (as long as wine gets to a point where it runs). To get steam client logs, piping steam-runtime output to some file would do. Alternatively, you could just run steam-runtime from a terminal and check the output "by hand" for some obvious issue.

[imaami]

I did a Debian unstable build of proton-tkg 5.19.r1 yesterday and tested curl; it still works. I also tried the same on upstream winehq Debian packages for both wine-devel 5.19 and wine-staging 5.19, and they also work.

So all in all from my point of view this bug remains fixed. But I'm wondering if the recent reverts in proton-tkg are still needed, given that upstream staging 5.19 works.

[Tk-Glitch]

Yes, due to other reverts in relation to ntdll/wineserver for esync/fsync. I'll gladly drop all of that when Zeb pushes updated esync to staging :frog:

[imaami]

Yes, due to other reverts in relation to ntdll/wineserver for esync/fsync. I'll gladly drop all of that when Zeb pushes updated esync to staging

Any day now, I'm sure! ;)

[kkartaltepe]

I had been testing VRChat and spelunky 2. VRchat had worked on normal wine/proton that come with arch/steam, I think spelunky had too though I didnt figure out I had to click through a prompt to get it to launch when using normal wine/proton.

The logs dont seem particularly interesting to me but there is nothing outside of loading DLLs before it prints nothing for a while and if left alone eventually exits with

/data/src/common/pipes.cpp (839) : Assertion Failed: fatal stalled cross-thread pipe                                   
/data/src/common/pipes.cpp (839) : Assertion Failed: fatal stalled cross-thread pipe                                 
/data/src/common/pipes.cpp (839) : Fatal assert failed: /data/src/common/pipes.cpp, line 839.  Application exiting.     

/data/src/common/pipes.cpp (839) : Fatal assert failed: /data/src/common/pipes.cpp, line 839.  Application exiting.

The full log should be available at http://paste.debian.net/hidden/988ed1a5/

Both games behave the same way. And die in the same way.

[kkartaltepe]

Rebuilding at wine/proton at 91e61cd4366052b70d49a0c6b5a110cabc32db8a with default settings and everything appears to be working normally again. Thanks for taking the time to help me try and debug these other issues and maintaining all these fixes!

[Tk-Glitch]

This should be all good now. Marking fixed.