Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Steam long commandline. #5753

Closed
fbt opened this issue Sep 13, 2018 · 6 comments
Closed

Steam long commandline. #5753

fbt opened this issue Sep 13, 2018 · 6 comments
Assignees

Comments

@fbt
Copy link

fbt commented Sep 13, 2018

Your system information

  • Steam client version (build number or date): Sep 8 2018, at 19:21:25
  • Distribution (e.g. Ubuntu): Arch
  • Opted into Steam client beta?: [Yes/No] Yes
  • Have you checked for system updates?: [Yes/No] Yes

Please describe your issue in as much detail as possible:

Steam stops reacting to external commands (ex. steam -shutdown) if you feed it a long enough commandline. Weirdly, it seems to vary, but a thousand chars does this reliably.

Steps for reproducing this issue:

  1. Launch Steam
  2. Feed it a commandline of over about a thousand chars, example: steam -applaunch 107410 -world=empty -noSplash -skipIntro -cpuCount=4 -maxMem=24576 -maxVRAM=11263 -exThreads=7 -noLogs -mod=mods-available/da8fc\;mods-available/7efc6\;mods-available/a9849\;mods-available/fb94f\;mods-available/7ef7c\;mods-available/76f92\;mods-available/7c479\;mods-available/69e77\;mods-available/bd6e9\;mods-available/42b88\;mods-available/665dc\;mods-available/b40a6\;mods-available/1e4ca\;mods-available/5528c\;mods-available/1878d\;mods-available/36b72\;mods-available/f4fb6\;mods-available/d79f8\;mods-available/2a801\;mods-available/fe52a\;mods-available/b0dd8\;mods-available/40496\;mods-available/4a200\;mods-available/c19a7\;mods-available/da7a1\;mods-available/3ecc8\;mods-available/74396\;mods-available/dc1d1\;mods-available/2fe45\;mods-available/ea285\;mods-available/be4b9\;mods-available/58582\;mods-available/c23ee\;mods-available/525f2\;mods-available/d36d8\;mods-available/d8b51\;mods-available/4cfbf\;mods-available/f235e\;mods-available/07c56\;mods-available/d24f0\;mods-available/07256\;mods-available/c92e1\;mods-available/d7dfb\;mods-available/68f61\;mods-available/fb083\;
  3. Steam stops reacting to any and all external commands.

It won't spew anything out into the console when this happens.
Not sure how to debug this further.
Happens in both the stable and the beta Steam versions.

Probably a DBus issue?

@fbt
Copy link
Author

fbt commented Sep 13, 2018

This isn't a huge problem, I've already worked around it by making the commandline much shorter, but I think Steam should either allow longer commandlines or explicitly bark at you if you go over the limit.
This was a bit frustrating to pinpoint.

bastimeyer added a commit to bastimeyer/dayz-linux-cli-launcher that referenced this issue Apr 9, 2022
Resolves #9
Resolves #8

See ValveSoftware/steam-for-linux#5753

Steam seems to have issues with long launch arguments when calling it
via `steam -applaunch GAMEID ARGUMENTS`. This results in the client not
responding to any `-applaunch` attempts anymore, and it needs to be
restarted.

When trying to join servers with lots of mods, the `-mod=...` argument
can become too long for Steam to handle, so mod directories should not
be named by their mod ID and mod name and they should instead be kept as
short as possible. This comes at the cost of not being able to identify
mod directories easily anymore, but it's better than not being able to
join certain servers at all and having to restart Steam.

- Remove mod names from mod directory links
- Turn decimal mod IDs into ASCII char strings and convert to base64
@bastimeyer
Copy link

Could this issue please get some attention?

I'm the author of a launcher script for DayZ which needs to pass a long -mod=... argument to steam -applaunch 221100, similar to what has been described in the OP in regards to Arma 3.

In order to work around this issue, I had to update my launcher script so that it doesn't name mod directory links like $ID-$NAME and it now converts the decimal mod ID into a string of ASCII chars and base64 encodes it, to ensure a minimal length of mod directory names that get included in the game's -mod launch argument. This unfortunately makes mods unrecognizable in the game directory.

@DanielCeregatti
Copy link

DanielCeregatti commented Jul 2, 2022

I didn't find issue this when I originally reported my issue. I too was hopping to launch DayZ on Linux using a steam:// URL, but this issue prevents it for servers with many mods. I will close mine and flag it as a duplicate of this one.

To be clear, the ONLY way at the moment to join a DayZ server with a long -mods string from the Linux Steam client is to craft a %command% -nolauncher -server=1.2.3.4 -mod=... string and to use that in the launch options. Luckily @bastimeyer's script mentioned above helps with that.

Currently it's a lot of hoop-jumping just to play DayZ on Linux. Fixing this issue would go a long way to making that process easier.


steam:// URLs that are greater than 931 characters break the Steam client

Issue transferred from #8484.
@DanielCeregatti posted on 2022-03-15T00:00:47:

Your system information

  • Steam client version: Mar 10 2022 20:44:57
  • Distribution Debian bookworm (testing)
  • Opted into Steam client beta?: Yes
  • Have you checked for system updates?: Yes

Please describe your issue in as much detail as possible:

Invoke a steam:// URL of size > 931 characters. The Steam client does not react to this at all, and any subsequent invocation of a steam:// URL, even when of a smaller size, results in no reaction from the Steam client

Normally, when the Steam client is open from the terminal, its stdout/stderr will appear there. Subsequently, when a steam:// URL is invoked, it will react to these invocations, responding with both output in the terminal as well as executing the expected result, such as launching a game.

Steps for reproducing this issue:

  1. With Steam not already started, open a terminal, run steam from the command line. Wait for the Steam client to start. This is just to see the extra output.
  2. Open another terminal and run steam with a URL (or xdg-open, which is what is run when URLs are clicked in desktop apps / browsers):

steam steam://run/appid

  1. Observe as the terminal from which Steam was launched will begin to show output, and the Steam client launches the game specified by appid.

  2. Run steam from the terminal again, but this time with a very long URL: (The appid here is DayZ, with a legit URL designed to launch the game correctly with all the mods necessary to join the server, whose IP and port are also specified)

steam "steam://run/221100//-connect=135.148.136.199 -port=2402 -name=Dick -nopause -nolauncher -mods=@CF;@NamalskIsland;@NamalskSurvival;@DabsFramework;@DayZEditorLoader;@BuilderItems;@VPPAdminTools;@sVisual;@sFramework;@FS;@FHTC;@FHTC_FLS;@FHTC_MP;@FHTC_HR;@FHTC_T2;@FHTC_VMP;@FHTC_T1;@Notifications;@Trader;@Server_Information_Panel;@WindstridesClothingPack;@MuchStuffPack;@CJ187LootChest;@MuchDecos;@ModularVestSystem;@MasssManyItemOverhaul;@Spurgles_BagZ;@QuadlocksPack;@ZTVendingMachine;@AdvancedBankingExperimental;@BasicTerritories;@BuildEverywhere;@CodeLock;@MortysWeapons;@RevGuns;@RemasteredArmaWeaponPack;@AdvancedWeaponScopes;@HellRetexSurvival;@PsychoGamingBigBoysPack;@IRPLandRoverDefender110;@FlipTransport;@dbo_surfaces_nam;@DMSVehicleWeatherPerformanceIncrease;@MuchCarKey;@AmbientLight;@FlyingBirds;@GoreZ;@InventoryMoveSounds;@DayzNavigation;@EarPlugs;@CannabisPlus;@ZeroyFishingZ;@PerishableFoodFixed;@CollectableItems;@KeepitdeadProjectBR;@ZStuff;@MunghardsItempack;@Cabin_Mod_RaGed;@Cabin_Mod_CodeLock_RaGed;@FHTC_T4;@AerialFlares;"

  1. Observe as the terminal running the Steam client shows NO output from this invocation, and that subsequent invocations of steam:// URLs, regardless of size, cause no further reactions from the Steam client.

The above URL is one that has been crafted by a DayZ launcher I'm working on to support connecting from the DayZ client running on Linux with Proton in Steam. It works for launching DayZ using URLs that fall below the 931 character limit.

But I find it concerning that steam:// URLs stop working after the first time a large request is made, indicating that something internal has gone south. Buffer overflow, perhaps? We all know what those lead to...

Thanks for supporting Linux!


@DanielCeregatti commented on 2022-03-18T04:12:39:

The same thing happens when using steam -applaunch ....

e.g.: steam -applaunch 221100 '-mod=@1797720064-WindstridesClothingPack;@2529499382-Greenhell;@2621103156-Gas_Masks_Only;@1564026768-Community_Online_Tools;@1559212036-CF;@2716445223-Melkart_Beta' -connect=135.148.136.226:2602 -nolauncher -name=Dick

When that is run from a terminal, that command successfully launches DayZ with the mods and connects to the server.

But this command, which is > 931 characters:

steam -applaunch 221100 '-mod=@2735895032-Aerial_Flares;@2658965218-FHTC_T4;@2326108316-Cabin_Mod_CodeLock_RaGed;@2326103329-Cabin_Mod_RaGed;@1734713776-MunghardsItempack;@2384407442-ZStuff;@2608895186-Keep_it_dead_ProjectBR;@2575183443-Collectable_Items;@2224213321-Perishable_Food_Fixed;@1850623448-Zeroy_FishingZ;@1932611410-CannabisPlus;@1819514788-Ear_Plugs;@1791033033-Dayz_Navigation;@2444247391-Inventory_Move_Sounds;@1648967877-GoreZ;@2501812949-Flying_Birds;@2078722927-AmbientLight;@2049002856-MuchCarKey;@2518235197-DMS_Vehicle_Weather_Performance_Increase;@2311951200-dbo_surfaces_nam;@1832448183-FlipTransport;@1912237302-IRP_Land_Rover_Defender_110;@2428693622-PsychoGaming_Big_Boys_Pack;@1873064588-HellRetex_Survival;@2143128974-Advanced_Weapon_Scopes;@1793351435-Remastered_Arma_Weapon_Pack;@2273590683-RevGuns;@2155726353-Mortys_Weapons;@1646187754-Code_Lock;@2546583347-BuildEverywhere;@2398911445-Basic_Territories;@2413002744-Advanced_Banking;@2149462115-ZT_Vending_Machine;@2484279619-Quadlock_s_Pack;@2489196158-Spurgles_BagZ;@1566911166-Mass_sManyItemOverhaul;@1962144102-Modular_Vest_System;@1967655509-MuchDecos;@2345073965-CJ187_LootChest;@1991570984-MuchStuffPack;@1797720064-WindstridesClothingPack;@1680019590-Server_Information_Panel;@1590841260-Trader;@2353998362-Notifications;@2662802517-FHTC_T1;@2572633941-FHTC_VMP;@2603158109-FHTC_T2;@2602656458-FHTC_HR;@2483384706-FHTC_MP;@2488768779-FHTC_FLS;@2479057860-FHTC;@2428595209-FS;@2614334381-sFramework;@2469448088-sVisual;@1828439124-VPPAdminTools;@1565871491-BuilderItems;@2276010135-DayZ_Editor_Loader;@2545327648-Dabs_Framework;@2289461232-Namalsk_Survival;@2289456201-Namalsk_Island;@1559212036-CF' -connect=135.148.136.199:2402 -nolauncher

When run from the terminal, there is no reaction from the running Steam client, and subsequent calls to the first command (or any other steam:// URL or steam -whatever command) no longer, as previously described. Only restarting the Steam client restores this capability of invoking the launching of Steams games from outside of steam (as long as they're not > 931 characters)

As I've been reading about how to launch Steam games from outside of Steam in a portable manner, I've read that the "correct" and most portable way is to use steam:// URLs, or make calls to steam -applaunch, as any other way relies on shelling out to the game from within the OS. With Proton on Linux, there is no easy way to do this. Unless this length limit is increased, people like me will not be able to write launchers for games whose launch commands exceed this built in limit.

But really, the fact that this stops working once it's trigger, IMO, indicates some buffer is being overrun, and that's never good. Maybe I'll start seeing what executable payload I can start adding after the 931st character...

I don't have windows, but I suspect this is an issue there as well.

Thanks gain for supporting Linux!


@chris-echoz commented on 2022-03-29T13:35:23:

For what it's worth the same issue occurs if you write something longer than 1023 characters into ~/.steam/steam.pipe.

Running head -c1024 /dev/urandom | base64 -w0 | head -c1022 | sed 's/$/\ /' > ~/.steam/steam.pipe (1023 chars including newline) Steam prints ExecCommandLine:..., and continues responding to input through the pipe.

Running head -c1024 /dev/urandom | base64 -w0 | head -c1023 | sed 's/$/\ /' > ~/.steam/steam.pipe (1024 chars) yields no output from Steam and causes the pipe to stop responding, even to proper input such as steam://store.

When testing this I also noticed that the pipe expects a newline before it takes any action and will concatenate the input of separate writes until it finds a newline. Unfortunately splitting input into smaller chunks still caused the same problem. Example: head -c1024 /dev/urandom | base64 -w0 | head -c512 > ~/.steam/steam.pipe && head -c1024 /dev/urandom | base64 -w0 | head -c512 > ~/.steam/steam.pipe && echo > ~/.steam/steam.pipe still triggers the same behavior

What's worse, if this really is a buffer overflow, is that clicking links on the web will also trigger this behavior if they contain a steam:// URL that's too long. POC: https://s.echoz.io/steam_url_bug.html


@chris-echoz commented on 2022-03-29T13:55:26:

I had a friend on Windows test my POC and this behavior does not appear to be present there. The store link and desktop shortcuts (which as far as i know also use steam:// URLs) remained functional after clicking the long link.


@DanielCeregatti commented on 2022-07-02T23:58:11:

Duplicate of #5753

@RokeJulianLockhart
Copy link

RokeJulianLockhart commented Aug 24, 2022

#5753 (comment)

This limit should definitely be removed. I do not believe that mere notification of the problem to the user would remediate anything. Additionally, I am certain that the limit truly should become unlimited rather than the limit merely be configured to be greater, because that merely delays the problem until somebody else attempts something more unique and impressive.

@vitorhnn
Copy link

From some very quick testing, this seems to have been quietly fixed by Valve at some point between October and now, or at least the size of the buffer Steam uses has been greatly expanded. steam:// URLs of over 19000 bytes now are properly executed.

If anyone else can verify this it'd be greatly appreciated!

@kisak-valve
Copy link
Member

Closing per the last comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants