Steam: Easy Anti-Cheat does not work under Void

[Cynosphere]

Is this a new report?

Yes

System Info

Void 6.0.15_1 x86_64 AuthenticAMD notuptodate FFFFFFFF

Package(s) Affected

steam-1.0.0.75_2 (theoretical)

Does a report exist for this bug with the project's home (upstream) and/or another distro?

https://github.com/ValveSoftware/Proton/issues/1199#issuecomment-1368284488 https://github.com/void-linux/void-packages/pull/34902#issuecomment-1255715853 https://github.com/ValveSoftware/Proton/issues/6051

Expected behaviour

Games using Easy Anti-Cheat run fine.

Actual behaviour

Games using Easy Anti-Cheat seem to not initialize Easy Anti-Cheat properly.

Steps to reproduce

VRChat:

1. Launch game through Steam
2. Login if fresh install
3. Be greeted with "Can't Travel" screen explaining Easy Anti-Cheat hasn't been initialized.

Apex Legends:

1. Launch game through Steam
2. Wait to get to the main menu
3. Be greeted with Engine Error message box saying "Easy Anti-Cheat Hash Catalogue not found"

[nekopsykose]

I already tested those:

ah right, not any of those then, sorry for the noise :)

[okawo80085]

Lmfaoooooooooo, so with glibc-2.38_4, current latest upstream version of glibc and Proton Experimental, EAC doesn't crash anymore, BUT it kicks you from game like a minute or so after start of the match cuz it fails anticheat authentication x) Gonna try with some other proton versions in a bit, but really not sure where to start with the failed authentication stuff, cuz there is nothing wrong in the eac logs now :/

[okawo80085]

Ohhhhh, looking at the steam client terminal output when i run the game with GE-Proton8.27, found this gem

LogActor: Warning: SetReplicates called on non-initialized actor BP_Projectile_M18_C_2147460702. Direct
ly setting bReplicates is the correct procedure for pre-init actors.

LogNet: Warning: UNetDriver::ProcessRemoteFunction: No owning connection for actor BP_Character_Player_
C_2147476777. Function ServerSetCameraIsTargetingKillLocation will not be processed.

LogINSPlayerController: Display: Kicked by server: Anti-Cheat: Authentication timed out (1/2).
LogNet: Error: UEngine::BroadcastNetworkFailure: FailureType = ConnectionLost, ErrorString = Your conne
ction to the host has been lost., Driver = GameNetDriver IpNetDriver_2147477057
LogNet: Warning: Network Failure: GameNetDriver[ConnectionLost]: Your connection to the host has been l
ost.
LogINSParty: Warning: EndCurrentMatch : Reset latest party data.
LogStreaming: Display: FlushAsyncLoading: 1 QueuedPackages, 0 AsyncPackages
LogLoad: Warning: UINSGameInstance::OnPreLoadMap: Invalid NextURL, loading /Game/Maps/Utility/Entry
LogEOSAntiCheat: Display: EndSessionClient : Result : (EOS_InvalidParameters)
LogEOSAntiCheat: Display: BeginSessionClient : Result : (EOS_InvalidParameters)

Anyone seen anything like this before?

[Naia-love]

Lmfaoooooooooo, so with glibc-2.38_4, current latest upstream version of glibc and Proton Experimental, EAC doesn't crash anymore, BUT it kicks you from game like a minute or so after start of the match cuz it fails anticheat authentication x) Gonna try with some other proton versions in a bit, but really not sure where to start with the failed authentication stuff, cuz there is nothing wrong in the eac logs now :/

Have you tried with more than one game ? (that you know it behavior before said update of glibc) or your game got updated? because what you're discribing was already something that was happening on some game (ie Vrchat, and that for at least as long as i started contributing to this issue) for apex legend iirc it'd happen if you'd move manually the eac library from the proton eac inside the game folder

[nonchip]

Anyone seen anything like this before?

@okawo80085 yes, that's the server kicking you for not passing the EAC check (and as usual your log doesn't contain any better info, but dont worry that's not on you, that's just because anticheat "doesn't wanna help you beat it" so just gives you 0 info), that's what this whole issue is about :D

the crash was just a temporary side effect of it going even wronger than usual. or like @Naia-love suggests it might be just the game or proton having been crashy with EAC not even to blame for that part.

[okawo80085]

Well damn, i ran out of time to test with anything else yesterday, was testing with Insurgency Sandstorm, gonna try to test with a few more EAC games today

[Dekomoro]

According to an Arch Linux commit(https://gitlab.archlinux.org/archlinux/packaging/packages/glibc/-/commit/83899c6e216ef04a56f16faaa19fcbf84bd0f799) valve has reported all affected easy anti cheat titles to be patched to not require -hash-style=both.

[nonchip]

@Dekomoro yup that confirms the theory we already had that the hash thing is not the main cause, because (in my and some others' experience above) EAC never really worked on void even tho the hash change only happened last year :P

added it to my big notes list above :)

[Naia-love]

@Dekomoro yup that confirms the theory we already had that the hash thing is not the main cause, because (in my and some others' experience above) EAC never really worked on void even tho the hash change only happened last year :P

not exactly im sure it worked for a while, but it definitively broke before the glibc hash change

[nonchip]

@Naia-love wait you're literally one of the sources supporting that conclusion :grin: what exactly do you mean by "i'm sure"? like are you guessing or reporting? because i for one have used void-glibc since the release dates of proton and EAC, and it never worked. like we're talking pre-DXVK already there.

[Naia-love]

huh? okay my memory may be wrong then i recall playing apex on void without using flatpak but yea been too much time could have been on another distro ig

[Naia-love]

I confirm, going through convo with freinds, at least apex did work for a while

but yes dosent change the fact that its a void problem and isnt linked to the hash change (as we already knew since here )

[nonchip]

@Naia-love keep in mind plenty games also release/betatest/etc without malware and only choose to become a broken mess for no decent reason after "1.0 release" or "official sale" or whatchamacallit. maybe it used to work because it simply didn't care yet? :D

also apex specifically broke and unbroke their own anticheat.so about 20 times so far with what can only be explained by people with zero clue pushing the wrong "release to live without any testing" button, usually then followed by an accidental autoban of the whole customer base, so honestly no idea what they're doing/how reliably/correctly they even use EAC.

[Naia-love]

@Naia-love keep in mind plenty games also release/betatest/etc without malware and only choose to become a broken mess for no decent reason after "1.0 release" or "official sale" or whatchamacallit. maybe it used to work because it simply didn't care yet? :D

that not impossible ig, but it do have eac since release, so well xD but unfortunaly I havent played any other game with eac at that time (or i cant recall at least), any other eac game i played was after it broke.

also apex specifically broke and unbroke their own anticheat.so about 20 times so far with what can only be explained by people with zero clue pushing the wrong "release to live without any testing" button, usually then followed by an accidental autoban of the whole customer base, so honestly no idea what they're doing/how reliably/correctly they even use EAC.

yes I remember that, most of time just grabbing the eac lib from the proton folder would work tho

[nonchip]

@Naia-love do you happen to remember when abouts that was (something like "summer last year" should be accurate enough)? could be worth comparing the versions we had back then, maybe we also accidentally unbroke our libc for a while without realizing and rebroke it since :'D

[Naia-love]

@Naia-love do you happen to remember when abouts that was (something like "summer last year" should be accurate enough)? could be worth comparing the versions we had back then, maybe we also accidentally unbroke our libc for a while without realizing and rebroke it since :'D

around start of 2022

[nonchip]

@oreo639 while i can't confirm that EAC worked for me before that (in fact i know that it didn't work for me, but in different games, so might be different reasons?), the first commit after that timeframe would be your update to 2.36, maybe you have some deeper insight? you asked about that version specifically all the way up.

also need to keep in mind though that we can't really know what EAC changed about their "rules" over the time. might well do all kinds of different things depending on the "build config" of the game even.

[okawo80085]

Well, i decided to try comparing the same game on flatpak steam vs native steam package. When using native package steam still the same anti cheat validation failed in Insurgency Sandstorm

LogEOSAntiCheat: Display: EndSessionClient : Result : (EOS_InvalidParameters)
LogEOSAntiCheat: Display: BeginSessionClient : Result : (EOS_InvalidParameters)

However when using flatpak steam, it works fine??? It also dumps these logs

LogEOSAntiCheat: Display: EndSessionClient : Result : (EOS_NotConfigured)
LogEOSAntiCheat: Display: BeginSessionClient : Result : (EOS_Success)

So im starting to have a feeling that this might be somehow tied into the native steam package as well...

[Naia-love]

Well, i decided to try comparing the same game on flatpak steam vs native steam package. When using native package steam still the So im starting to have a feeling that this might be somehow tied into the native steam package as well...

theres very little to no chance its that flatpak use its own system lib (i dont wanna say bs as i dont know how it exactly work, but its kinda like if you do a chroot with others libs, like if you're on musl and do a glibc chroot of void, steam will work inside the glibc chroot. and btw steam also work on musl void with flatpak) so as it useit own glibc, if its indeed the glibc void build the culprit (which we are like asfar i understood the thread, pretty sure), well its fiked cuz it use it own mot bugged

[okawo80085]

Well, how about we take a look at how flatpak builds their system lib and how it differs from ours?

[Naia-love]

Well, how about we take a look at how flatpak builds their system lib and how it differs from ours?

we are already doing so with arch

[classabbyamp]

flatpak does not use the system glibc. it is a container fully independent of the system

[okawo80085]

flatpak does not use the system glibc. it is a container fully independent of the system

Well yeah, but its not like its built from some magical source, the steam package manifest can be found here And last time i checked freedesktop's stuff is also open source.

I started to look through it, and a few things i already noticed is that void's native package for steam is missing some deps compared to the stuff that flatpak is installing.

[okawo80085]

Also worth taking a look at what this repo that has a patch Arch's glibc to work with EAC repo with the patch: https://github.com/Frogging-Family/glibc-eac/blob/main/disable_tests.patch Arch's glibc recipe: https://github.com/archlinux/aur/blob/glibc-x86_64/PKGBUILD

[okawo80085]

Also as per this relatively ancient gentoo thread, building glibc with libc_cv_hashstyle=no made their EAC work again, but idk how relevant it is now https://forums.gentoo.org/viewtopic-t-1147585.html?sid=ff98ea1836909e193ed668f5fd0430b5

I got glibc to build, but its inconsistant af, and if i try to link against the built libs instead of void-package ones steam refuses to start saying glibc has the wrong elfclass x) So need to figure that one out before i can really do any proper testing :/

[nonchip]

@okawo80085 i'm rather positive that digging up already ruled out or clearly established things in a bunch of individual unedited spammy posts with less research than above won't bring us further, please scroll next time. DT_HASH has been beaten to death and back now (to the point of me already having made up a joke hashtag above), and literally the 2nd post (that isn't just "logistics") on this topic is about how flatpak works by not using our libc!

and why would we look at a 3rd party "patch to make arch libc work" if arch libc works plenty without it and is the thing we've been comparing to so far as the known good one? especially since that patch is completely unrelated and just to make that repo's build thingy happy by turning off some optional tests?

[caszuu]

i not sure if anyone has found a way (apart from Flatpaks) to launch eac successfully so i'm just posting this here in case it could lead to the root cause.

I found a way to launch vrchat successfully by forcing steam to run the game outside of it's "Steam Linux Runtime 3.0 (Sniper)" wrapper using vrchats launch options in steam.

When you launch the game normally and watch steam clients output for the launch command it will be some form of this

<steam path>/reaper -- <steam path>/steam-launch-wrapper -- <linux runtime path>/_v2-entry-point -- <proton path>/proton <vrchat path>/launch.exe

This way vrchat fails to connect with eac and quits. But when you copy the command and remove the Steam Runtime wrapper (removing the _v2-entry-point while leaving the reaper and steam-launch-wrapper) and put the full command into the steam launch options like this

<steam path>/reaper -- <steam path>/steam-launch-wrapper -- <proton path>/proton <vrc path>/launch.exe # %command%

the game and eac launch successfully.

This is a scuffed setup to say the least but it most likely rules out glibc from being the problem. It seams there's an issue when running an eac game inside the steam runtime as vrc couldn't even detect eac always logging

[AntiCheatClient] Anti-cheat client not available. Verify that the game was started using the anti-cheat bootstrapper if you intend to use it.

even tho the eac service did launch without errors.

[ghost]

This method works for Elden Ring and Armored Core 6, thanks.

[Dekomoro]

since it's narrowed to the runtime, I thought it might be worth bringing up this page. If special cases are needed they offer the ability to contact them. This was done with exherbo, which is another independent distro. It lists all the common dependencies and such. https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/main/docs/distro-assumptions.md

[Dekomoro]

So apparently the steam linux runtime calls all of it's scripts with #!/bin/sh. I'm seriously suspecting some bashisms being the culprit here. I am not available right now for investigation so if someone could look into that as a possibility?

[classabbyamp]

you can run shellcheck on the scripts, maybe. some of the lints it raises are about bashisms in posix sh

[trizey]

<steam path>/reaper -- <steam path>/steam-launch-wrapper -- <linux runtime path>/_v2-entry-point -- <proton path>/proton <vrchat path>/launch.exe

<steam path>/reaper -- <steam path>/steam-launch-wrapper -- <proton path>/proton <vrc path>/launch.exe # %command%

Ran into this EAC issue this evening with Sea of Thieves and this workaround makes it playable again. Cheers for sharing it.

I'll try to contribute some time to this issue if its helpful, but I'm late to this party and getting caught up in this thread.

[Natthias]

Bashisms aren't the issue, symlinkg /bin/sh to bash doesn't fix EAC in my glibc chroot

[nonchip]

@trizey pretty sure that's something else, since Sea of Thieves never had this issue.

[trizey]

@trizey pretty sure that's something else, since Sea of Thieves never had this issue.

@nonchip Sea of Thieves enabled EAC recently in March. The error I was getting trying to login to the server was "EAC failed to initialize" to which the workaround mentioned in this thread fixes it. Seems pretty related to me.

[nonchip]

@trizey oh sorry yeah i haven't actually played in a few months, i wasn't aware that was new, thought they'd been using it for a while. yeah then it's related.

[DiarrheaMcgee]

ive seen this issue happen every time as of that update on 2 different void linux computers (gentoo still works but im sticking with void)

[okawo80085]

Tested again today on Void 6.6.29_1 x86_64 AuthenticAMD notuptodate rrrrmmnFFFFFFF, EAC still fails with native steam, tested with VRChat and Insurgency, same errors as before EAC failed to initialize, all while the same games work fine on flatpak version on steam :/ If its not glibc, maybe its missing some shared lib dep or there is some dep version miss match?

[Norman-Normandy]

Don't know if this is relevant, but "nProtect GameGuard" for helldivers 2 works perfectly fine. Only EAC games don't work as they complain about hashing issues. Both the linker and libc.so appear to have both DT_GNU_HASH & DT_HASH symbols. I'm curious if there's something somehow preventing it from being reliably detected.

[okawo80085]

Just poping in to say that this is still very much an issue, except games like Insurgency stopped logging to console stuff like EAC status so its harder to debug now :melting_face:

[caszuu]

@okawo80085 did you try the workaround above or does eac not work at all? For me running eac outside of the runtime still works just as well.

From what i can tell with limited testing i did, the bug seems to be fully pressure-vessel related and can confirm that umu also reproduces the same issue. (as it ships it's own steam linux runtime) I lack the skills to properly debug this but i wonder if it's some conflict between Void's fs structure and the path whitelist provided by pressure-vessel or something similar.

[Tyfuzzle]

@caszuu where do I get the command steam uses to launch a game from for the workaround? I can't see it in the steam terminal output and proton logs don't have anything (pretty sure it wouldn't be there since it's called mid-command, not before it).

[caszuu]

@Tyfuzzle huh i swear that steam used to print the command to stdout just a while ago, but i can't find it today either. One quick way to get the launch command is to start the game and get the command from htop in tree mode, the command your after is the /bin/sh one owning the game process

[Tyfuzzle]

@caszuu thanks. Got the command. It was showing in htop but the command was too long so I ended up doing this:

ps -ef | grep reaper

Can also confirm the workaround appears to work for me with Halo MCC.

[okawo80085]

@okawo80085 did you try the workaround above or does eac not work at all? For me running eac outside of the runtime still works just as well.

From what i can tell with limited testing i did, the bug seems to be fully pressure-vessel related and can confirm that umu also reproduces the same issue. (as it ships it's own steam linux runtime) I lack the skills to properly debug this but i wonder if it's some conflict between Void's fs structure and the path whitelist provided by pressure-vessel or something similar.

Hi, no i didn't, gonna try it in a bit

[okawo80085]

Ok so i tried it, a few notes, proposed fix forgot to mention that the proton command needed an additional argument and some environment variables setup to work correctly, the actual command ended up looking something like this for me

$STEAM_PATH/reaper -- $STEAM_PATH/steam-launch-wrapper -- $PROTON_PATH/proton run $APP_BIN

However this did not fix anything, i tested it with Insurgency Sandstorm, kicked from the match 5 minutes after start by EAC

Gonna try with VRChat later, but dont have much hope for it to work :L

[Naia-love]

Ok so i tried it, a few notes, proposed fix forgot to mention that the proton command needed an additional argument and some environment variables setup to work correctly, the actual command ended up looking something like this for me

$STEAM_PATH/reaper -- $STEAM_PATH/steam-launch-wrapper -- $PROTON_PATH/proton run $APP_BIN
`

I dont know why you had to do that. I did the setup like monday to play and i didnt do anything than copy the command steam run, delete the v2 entry point part of it (and put in " " for the proton part as its proton 9 and it have a space in it path :^)

However this did not fix anything, i tested it with Insurgency Sandstorm, kicked from the match 5 minutes after start by EAC

Gonna try with VRChat later, but dont have much hope for it to work :L

Vrchat worked fine for me last time I tried. And i played elden ring online litteraly yesterday its maybe because of what you changed?

[okawo80085]

Maybe it was because i was using Proton Experimental instead of Proton 9?

[okawo80085]

Noup, Proton 9 has the same arg parse, so i dont understand how you managed to start it without telling it to use run or any of the other available modes

[Naia-love]

Noup, Proton 9 has the same arg parse, so i dont understand how you managed to start it without telling it to use run or any of the other available modes

and i dont understand why you need it x) I could copy past you my steam launch option and you would just need to change to match your dir I suppose. Im not home tho rn