Steam runtime in distrobox causes some games to have broken network functionality

[orowith2os]

Your system information

• Steam Runtime Version: Latest used with Proton and native
• Distribution (e.g. Ubuntu 18.04): Arch Linux repositories inside of distrobox, Fedora Silverblue 38 on the host
• Link to your full system information (Help -> System Information) in a Gist: https://gist.github.com/orowith2os/c351e9c3c36d0380abeed427fa17b887
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Proton 6, Experimental, and GE
• If you are using Steam Linux Runtime, or Proton 5.13 or newer: What versions are listed in SteamLinuxRuntime_soldier/VERSIONS.txt?

Name Version Runtime Runtime_Version Comment

depot 0.20230314.45274 # Overall version number pressure-vessel 0.20230314.0 scout # pressure-vessel-bin.tar.gz scripts 0.20230314.0 # from steam-runtime-tools soldier 0.20230314.45274 soldier 0.20230314.45274 # soldier_platform_0.20230314.45274/

Please describe your issue in as much detail as possible:

When running Proton games using the default Steam Linux Runtime inside of distrobox, some will have broken network functionality:

• Halo MCC will be stuck on getting matchmaking data from 343
• Halo Infinite will show as offline and not allow online functionality

Using a native runtime has no such issue.

Steps for reproducing this issue:

1. Create an Arch Linux distrobox container with all the necessary Steam dependencies
2. Install Steam
3. Install Halo MCC or Halo Infinite
4. Run either game (preferably MCC, as that's more stable) and go to multiplayer
5. Watch as the game either tells you no network is available or gets stuck on downloading matchmaking data

When ran with steam-native-runtime, there are no network issues.

I'd appreciate some bare bwrap commands that I can use to see where the issue lies. If I find the setting that causes it to work, or if it only works when I mount in a flatpak runtime or the host, I'll notify this issue.

Originally made at https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/issues/105, moved here per the request of @smcv

[J-C-3]

Hey @orowith2os !

I had your exact issue with a "bare metal" installation on arch as well and came across this issue.

As far as I can tell, the issue stemmed from me disabling IPv6 on my internal network and the Xbox live services appear to rely on IPv6.

My ISP had routing issues with IPv6 years ago leading to high latency and I just disabled it since it was the path of least resistance.

I'm not too familiar with distrobox at all but I used it to spin up a rootless container to take a peek.

It looked like IPv6 was functioning with the podman container. When attempting to fire up Halo Infinite, it hung during the initial loading screen and appeared to crash and since I was just poking at it I kinda stopped there.

You might want to check for IPv6 functionality within your container and see if that can help lead you in the right direction.

Still might be an issue with the steam runtime, since native seemed to work for you, but it's something to check at the very least.

Anyways, thought I'd mention it.

[orowith2os]

I'm verifying my game files at the moment, as I just finished migrating my games to a compressed btrfs drive, so it might be a while, but....

I don't have functioning IPv6 on my network, so it's all local addresses; I'll disable it completely on my machine's network adapter and report back if it helps any.

[J-C-3]

Best of luck! Let me know how it goes!

[smcv]

Please get a container runtime log with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment but no special workarounds, and attach it here or as a Gist, so that what is going on in your situation can be investigated.

It sounds as though you have a workaround, possibly to do with steam-native-runtime. If so, please get a similar log with your workaround; then provide that second log here (please be as clear as possible about which log is which and what you did differently), or compare them yourself.

Other debugging steps that could be useful:

• If you run with PRESSURE_VESSEL_SHELL=instead in the environment, you'll get an xterm inside the container, which you can use to explore that environment interactively. This would help to narrow down exactly what is going wrong (DNS resolution, IPv4 vs IPv6, something else).
• Running a native Linux game that does network things with the Steam Linux Runtime compatibility tool forced in its Steam properties, instead of a Windows game via Proton, would remove a significant amount of complexity from the situation by not using Proton. That would help to narrow down whether this is triggered by the container runtime, or by Proton.

When running Proton games using the default Steam Linux Runtime inside of distrobox, some will have broken network functionality

We don't/can't really support running the Steam container runtime inside distrobox: containers inside containers are often not possible to make reliable, and if the "outer" container has meaningful sandboxing (like Flatpak, Docker or Podman) then it will often prevent the "inner" container from starting at all.

Having said that, the Steam container runtime's bubblewrap invocation inherits the network namespace from the environment where Steam is running (in your case that's inside distrobox?), so in principle, as long as bubblewrap works at all, anything that works there should generally also work inside the container runtime environment.

Are you able to find out what exactly "network functionality" means here? DNS name resolution? Connecting to an IPv4 server? Connecting to an IPv6 server? Something else?

Using a native runtime has no such issue.

What do you mean by "native runtime", precisely? Different people use those words to mean different things.

When ran with steam-native-runtime, there are no network issues.

Arch Linux's steam-native-runtime is not supported or supportable: it disables Steam compatibility mechanisms that are there for a reason.

However, as far as I'm aware, steam-native-runtime only affects the LD_LIBRARY_PATH Steam Runtime (used to run Steam and most native Linux games), and does not alter the behaviour of the Steam Linux Runtime container runtime (used to run Proton 5.13+ and a few newer native Linux games). So if it has an effect here, I'm surprised by that.

I'd appreciate some bare bwrap commands that I can use to see where the issue lies. If I find the setting that causes it to work, or if it only works when I mount in a flatpak runtime or the host, I'll notify this issue.

The container runtime log with STEAM_LINUX_RUNTIME_VERBOSE=1 will contain the full bwrap command-line that pressure-vessel used. It is programmatically-generated and very long (similar to what you'd get from Flatpak) and depends on properties of your system, so I cannot quote a simple/short bwrap command-line that will have the same effect.

[orowith2os]

I've gotten quite busy in the past while, so I can't test everything just yet, but I'll be sure to give it a try when I can. I still need to try that IPv6 workaround.

And to note: full bubblewrap should work in distrobox, they don't make any attempt to sandbox it from the host. It's meant to be very tightly integrated with the host, from the home folder to /tmp.

I've also used bubblewrap within distrobox myself and it works just fine.