Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent 4b6b19ea0f
commit 5c378fa70f488162116b41b66c08b6729f37ae43
2 changed files
with 109 additions and 0 deletions
fix-invalid-steam-userid-ticket/en.md
A
| @@ -0,0 +1,55 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Players Kicked for 'Invalid STEAM UserID Ticket'" | |
| 3 | +excerpt: "The 'Invalid STEAM UserID Ticket' kick means the server rejected the client's Steam auth. Either allow non-Steam clients with Reunion/dproto, or fix the Steam auth path. Both covered." | |
| 4 | +category: "errors" | |
| 5 | +tags: "steamid, validation" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>A player connects, then is dropped with:</p> | |
| 10 | +<pre>Invalid STEAM UserID Ticket</pre> | |
| 11 | +<p>This means the server asked Steam to validate the client's identity and the validation failed or never completed. There are two entirely different situations behind it, and the fix depends on which one you are in: you are running a non-Steam server and want non-Steam clients to join, or you are running a Steam-authenticated server and the auth path is broken.</p> | |
| 12 | + | |
| 13 | +<h2>1. Decide which server you are running</h2> | |
| 14 | +<p>If your community is non-Steam (pirated clients, common in many regions), a stock server will reject every one of them with this ticket error, because they have no valid Steam ticket to present. The fix is to install a client-authentication emulator: <strong>Reunion</strong> on ReHLDS, or <strong>dproto</strong> on original HLDS. If your server is meant to be Steam-only and legitimate Steam users are being kicked, skip to step 4.</p> | |
| 15 | + | |
| 16 | +<h2>2. Non-Steam: install Reunion (ReHLDS)</h2> | |
| 17 | +<p>Reunion is a Metamod plugin that lets non-Steam clients authenticate while still allowing real Steam clients. It requires <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> and <a href="/tutorials/install-metamod-r">Metamod-r</a>. Drop the Reunion binary into <code>addons/reunion/</code> and register it in Metamod's plugin list:</p> | |
| 18 | +<pre>// addons/metamod/plugins.ini | |
| 19 | +linux addons/reunion/reunion_mm_i386.so</pre> | |
| 20 | + | |
| 21 | +<h2>3. Configure reunion.cfg — the salt is mandatory</h2> | |
| 22 | +<p>Reunion needs a <code>SteamIdHashSalt</code> of <strong>at least 16 characters</strong> or it refuses to load. This salt is what generates stable IDs for non-Steam players, so admin flags and stats stay attached to the right person. In <code>addons/reunion/reunion.cfg</code>:</p> | |
| 23 | +<pre>SteamIdHashSalt = a-long-random-string-min-16-chars | |
| 24 | + | |
| 25 | +// which client types to accept | |
| 26 | +cid_Steam = 0 | |
| 27 | +cid_NoSteam = 2</pre> | |
| 28 | +<p>Pick a random salt and <strong>never change it afterwards</strong> — changing the salt re-hashes every non-Steam SteamID, wiping every player's admin access and stats in one restart. Keep it secret and backed up.</p> | |
| 29 | + | |
| 30 | +<h2>4. Steam-only server: fix the auth path</h2> | |
| 31 | +<p>If you want genuine Steam validation and real users are kicked, the server itself cannot reach Steam auth. Common causes:</p> | |
| 32 | +<ul> | |
| 33 | +<li>The engine is too old after the 2023 25th-Anniversary update. Update HLDS, or move to ReHLDS.</li> | |
| 34 | +<li>Missing Steam runtime files. The server needs <code>steamclient.so</code> and a <code>steam_appid.txt</code> present; without them it silently falls back and cannot validate tickets.</li> | |
| 35 | +<li>You launched with <code>-insecure</code> expecting security, or the reverse — check your launch line.</li> | |
| 36 | +</ul> | |
| 37 | +<p>Confirm the runtime files exist next to the engine and re-run <code>app_update 90 validate</code> in SteamCMD if they are missing.</p> | |
| 38 | + | |
| 39 | +<h2>5. Do not mix Reunion with a secure/VAC expectation</h2> | |
| 40 | +<p>Once Reunion is accepting non-Steam clients, the server is by definition not VAC-secure — that is the trade. Run it <code>-insecure</code> to avoid the misleading "not VAC secured" churn, and rely on <a href="/tutorials/install-rechecker">ReChecker</a> and admin tooling for integrity instead.</p> | |
| 41 | + | |
| 42 | +<h2>6. Original HLDS: use dproto instead</h2> | |
| 43 | +<p>If you are on stock Valve HLDS rather than ReHLDS, Reunion is not the tool — dproto is. It is also a Metamod plugin and it serves the same purpose: accepting both Steam and non-Steam clients and giving non-Steam players a stable ID. Install it into <code>addons/dproto/</code> and register it in <code>plugins.ini</code>, then configure the client acceptance modes in <code>dproto.cfg</code>. The design decision is the same as Reunion's salt: pick your ID-generation settings once and do not change them, or every non-Steam player's admin access and stats reset. The broader recommendation still stands — run <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> with Reunion rather than HLDS with dproto, because the ReHLDS stack is what is actively maintained.</p> | |
| 44 | + | |
| 45 | +<h2>Common errors</h2> | |
| 46 | +<ul> | |
| 47 | +<li><strong>Every client kicked with the ticket error</strong> — non-Steam community on a stock server; install Reunion or dproto.</li> | |
| 48 | +<li><strong>Reunion does not load</strong> — <code>SteamIdHashSalt</code> is missing or shorter than 16 characters. Check the AMXX/Metamod log for the refusal line.</li> | |
| 49 | +<li><strong>All admins lost access after an edit</strong> — you changed <code>SteamIdHashSalt</code>. Restore the old salt from backup.</li> | |
| 50 | +<li><strong>Only some clients kicked</strong> — those are non-Steam on a server configured Steam-only; adjust <code>cid_NoSteam</code>.</li> | |
| 51 | +<li><strong>Steam clients kicked after 2023 update</strong> — outdated engine; update or switch to ReHLDS, and have clients try the <code>steam_legacy</code> branch.</li> | |
| 52 | +</ul> | |
| 53 | + | |
| 54 | +<h2>Verification</h2> | |
| 55 | +<p>After configuring Reunion, connect with a client and check the console at connect time — the player should join without the ticket kick. In the server console, <code>meta list</code> must show Reunion as <code>RUN</code>. Then confirm IDs are stable by reconnecting: the player's SteamID (as seen in <code>amx_who</code> or the logs) must be identical across reconnects. If it changes each time, the salt is not being read.</p> |
fix-reliable-channel-overflowed/en.md
A
| @@ -0,0 +1,54 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Reliable channel overflowed' Disconnects" | |
| 3 | +excerpt: "What 'Reliable channel overflowed' really means, which plugins and HUD/menu spam cause it, and how to stop the per-client netchannel from bursting past its buffer." | |
| 4 | +category: "errors" | |
| 5 | +tags: "netchan, overflow" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p><code>Reliable channel overflowed</code> is the engine dropping a client because it queued more reliable network data for that player than the netchannel buffer can hold in one burst. Reliable messages are the ones the engine must deliver in order and cannot discard — HUD messages, menus, entity spawns, sounds triggered via reliable messages. When something floods a player with reliable data faster than it drains, the buffer bursts and that player is disconnected. It is a symptom of a plugin or a map event, not a bandwidth ceiling you can simply raise away.</p> | |
| 10 | + | |
| 11 | +<h2>1. Recognise the pattern</h2> | |
| 12 | +<p>Overflow that hits <strong>one player at a time</strong>, often right at spawn or on a specific event, points at reliable-message spam aimed at that player. Overflow that hits <strong>everyone at map start</strong> points at a mass precache/entity burst or a plugin blasting messages to all clients in one frame. The console line names the affected client, and the timing tells you the trigger.</p> | |
| 13 | + | |
| 14 | +<h2>2. The usual causes</h2> | |
| 15 | +<ul> | |
| 16 | +<li><strong>HUD/DHUD spam</strong> — a plugin writing many <code>message_begin</code>/<code>show_hudmessage</code> updates per second to a player.</li> | |
| 17 | +<li><strong>Giant menus</strong> — a menu rebuilt and re-sent every frame, or a very long motd/menu pushed at connect.</li> | |
| 18 | +<li><strong>Mass entity creation</strong> — a plugin spawning many entities at once (effects, decals, temp entities sent reliably).</li> | |
| 19 | +<li><strong>Advert/announcement plugins</strong> firing several long chat lines simultaneously to every player.</li> | |
| 20 | +<li><strong>Broken loops</strong> — a plugin bug re-sending the same reliable message in a tight <code>set_task</code> or per-frame hook.</li> | |
| 21 | +</ul> | |
| 22 | + | |
| 23 | +<h2>3. Give the netchannel more room (a little)</h2> | |
| 24 | +<p>Higher client rates let the buffer drain faster, which can absorb a marginal burst. In <code>server.cfg</code>:</p> | |
| 25 | +<pre>sv_maxrate 25000 | |
| 26 | +sv_minrate 8000 | |
| 27 | +sv_maxupdaterate 101 | |
| 28 | +sv_minupdaterate 30</pre> | |
| 29 | +<p>On <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> there are additional netchannel controls, but do not treat rate as the fix — if a plugin sends unbounded reliable data, no rate value saves you. Raising rates only buys headroom for a legitimately busy but bounded server.</p> | |
| 30 | + | |
| 31 | +<h2>4. Find the offending plugin</h2> | |
| 32 | +<p>Overflow that started after you added or changed a plugin is your prime suspect. Bisect with the standard method:</p> | |
| 33 | +<pre>amxx pause somepluginname | |
| 34 | +// or disable half the plugins.ini list, restart, retest</pre> | |
| 35 | +<p>See <a href="/tutorials/find-crashing-plugin">how to find which plugin is at fault</a> for the halving technique. Watch which player overflows and when — a plugin that acts on spawn, on connect, or on a specific weapon/event narrows it fast.</p> | |
| 36 | + | |
| 37 | +<h2>5. Fix the plugin behaviour</h2> | |
| 38 | +<p>The real fix is in the plugin: rate-limit HUD updates to a few per second instead of every frame, send menus once instead of rebuilding them continuously, and prefer unreliable temp-entity messages (<code>MSG_BROADCAST</code>/<code>MSG_PVS</code>) for cosmetic effects that do not have to arrive. If it is a plugin you did not write and cannot edit, replace it with one that behaves. Our own HUD/info plugins are written to stay inside the buffer — see the <a href="/plugins/csb-server-adverts">server adverts plugin</a> for an advert system that paces its messages instead of dumping them.</p> | |
| 39 | + | |
| 40 | +<h2>6. When it is the map or entity count, not a plugin</h2> | |
| 41 | +<p>A map that spawns a very large number of entities, or floods clients at load with a huge motd/overview, can overflow the reliable channel on join before any plugin runs. If overflow reproduces with every AMXX plugin paused and only on certain maps, the map is the source — you cannot rate-limit that away, only avoid or replace the map. On <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> the log line naming the overflowing client is more precise, which makes it easier to tell a per-player plugin flood from a map-wide one.</p> | |
| 42 | + | |
| 43 | +<h2>Common errors</h2> | |
| 44 | +<ul> | |
| 45 | +<li><strong>One player overflows at spawn every round</strong> — a spawn HUD or a per-player message loop. Rate-limit it.</li> | |
| 46 | +<li><strong>Everyone overflows at map start</strong> — a mass precache/entity burst or an advert plugin firing all lines at once on map load.</li> | |
| 47 | +<li><strong>Overflow only for high-latency players</strong> — their channel drains slowly, so a burst that fine connections absorb overflows theirs. The plugin is still the root cause.</li> | |
| 48 | +<li><strong>Started right after a config change</strong> — you enabled a chattier HUD or lowered <code>sv_maxrate</code>. Revert and confirm.</li> | |
| 49 | +</ul> | |
| 50 | + | |
| 51 | +<h2>Verification</h2> | |
| 52 | +<p>Reproduce the exact trigger — the map, the round moment, or the player action that caused it — with the suspect plugin paused, and confirm the disconnect no longer happens:</p> | |
| 53 | +<pre>status</pre> | |
| 54 | +<p>Watch the player through the moment that used to drop them. A clean pass with the plugin disabled proves the diagnosis; then re-enable a fixed or replacement version and repeat. If disconnects continue with all AMXX plugins paused, the trigger is the map or the engine, and you should test on a stock map to separate the two.</p> | |
| 0 | 55 |
