Add 2 tutorials (2 files)
Browse Source
Daemon666 committed
parent 7c60ac4d66
commit ed83c2dc3d9b63c41296757277890f2258995758
2 changed files
with 124 additions and 0 deletions
fix-bad-rcon-password/en.md
A
| @@ -0,0 +1,62 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: 'Bad rcon_password' / RCON Not Authenticating" | |
| 3 | +excerpt: "Every reason RCON rejects your password on a CS 1.6 server - config overrides, the challenge/UDP path, ReHLDS lockouts, and sv_rcon ban settings - with the exact check for each." | |
| 4 | +category: "errors" | |
| 5 | +tags: "rcon, auth" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>You type <code>rcon</code> commands and the server answers <code>Bad rcon_password.</code> or simply ignores you. RCON on the Half-Life engine is a challenge/response protocol over the same UDP port as the game, and there are only a handful of things that break it: the password the server actually loaded is not the one you think, you are locked out by too many failures, or your client never sent the right password at all. Work through them in order.</p> | |
| 10 | + | |
| 11 | +<h2>1. Confirm the password the server actually loaded</h2> | |
| 12 | +<p><code>rcon_password</code> is set in <code>server.cfg</code>, but it can be silently overridden by <code>autoexec.cfg</code>, by a per-map config, or by an amxx admin config. On the server console (local, no RCON needed) run:</p> | |
| 13 | +<pre>rcon_password</pre> | |
| 14 | +<p>It prints the current value. If it is empty, <strong>RCON is disabled entirely</strong> — the engine refuses all RCON when the password is blank, and that is the single most common cause. Set it and it must be non-empty:</p> | |
| 15 | +<pre>rcon_password "a-long-random-string-no-spaces"</pre> | |
| 16 | + | |
| 17 | +<h2>2. Kill the quoting and whitespace traps</h2> | |
| 18 | +<p>A password with a space in it, or a stray character from a copy-paste, is a frequent culprit. In a <code>.cfg</code> file the value must be quoted if it contains anything unusual, and it must not have a trailing space before the newline. A password saved from Windows Notepad can also carry a hidden carriage return. Prefer a plain alphanumeric password with no spaces, quotes, or shell metacharacters while you are debugging — you can harden it later.</p> | |
| 19 | + | |
| 20 | +<h2>3. Set the password on the client the right way</h2> | |
| 21 | +<p>From a CS 1.6 client console you must set <code>rcon_password</code> locally <strong>and</strong> be pointed at the server:</p> | |
| 22 | +<pre>rcon_password "a-long-random-string-no-spaces" | |
| 23 | +rcon status</pre> | |
| 24 | +<p>If you are not connected to the server, also set the address:</p> | |
| 25 | +<pre>rcon_address YOUR_SERVER_IP:27015</pre> | |
| 26 | +<p>A mismatch between <code>rcon_address</code> and the server you are actually on will send the RCON packet into the void and you will see <code>Bad rcon_password</code> or a timeout even though the password is correct.</p> | |
| 27 | + | |
| 28 | +<h2>4. Check you are not locked out (ReHLDS)</h2> | |
| 29 | +<p>On <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> there are anti-bruteforce cvars, and a few wrong attempts will lock your IP for a window. Look at them on the server:</p> | |
| 30 | +<pre>sv_rcon_maxfailures | |
| 31 | +sv_rcon_minfailures | |
| 32 | +sv_rcon_minfailuretime | |
| 33 | +sv_rcon_banpenalty</pre> | |
| 34 | +<p>The default behaviour bans an IP after <code>sv_rcon_maxfailures</code> bad attempts within <code>sv_rcon_minfailuretime</code> seconds, for <code>sv_rcon_banpenalty</code> minutes. While you are locked out, <em>even the correct password</em> is rejected. Wait out the penalty, or on the server console temporarily raise the limits:</p> | |
| 35 | +<pre>sv_rcon_maxfailures 10 | |
| 36 | +sv_rcon_minfailuretime 5</pre> | |
| 37 | +<p>Set them back to something strict once you are in — RCON brute-forcing is a real attack, not a hypothetical.</p> | |
| 38 | + | |
| 39 | +<h2>5. Make sure RCON traffic reaches the server</h2> | |
| 40 | +<p>Classic HLDS RCON rides UDP on the game port. Some hosts and firewalls treat RCON differently, and some panels expose a separate TCP RCON. If the game connects but RCON never answers, confirm the port is open both ways:</p> | |
| 41 | +<pre>ss -lunp | grep 27015</pre> | |
| 42 | +<p>If you administer through a web panel or a remote tool, that tool has its own address/password fields — a stale entry there produces the same <code>Bad rcon_password</code> while your in-game console works fine.</p> | |
| 43 | + | |
| 44 | +<h2>6. Did server.cfg even execute?</h2> | |
| 45 | +<p>If several settings besides RCON are also not applying, the whole <code>server.cfg</code> may not be running. It executes automatically only for the default map load; a custom map-start sequence, a mapcycle that skips it, or a bad filename (<code>server.cfg.txt</code> from Windows Explorer hiding the real extension) all leave it un-executed. Force it once and re-check:</p> | |
| 46 | +<pre>exec server.cfg | |
| 47 | +rcon_password</pre> | |
| 48 | +<p>If <code>rcon_password</code> is now correct after a manual <code>exec</code> but was empty before it, the file exists and is right — it simply was not being run at startup, and that is the real bug to chase.</p> | |
| 49 | + | |
| 50 | +<h2>Common errors</h2> | |
| 51 | +<ul> | |
| 52 | +<li><strong><code>Bad rcon_password.</code></strong> with a correct password — you are inside a ReHLDS failure lockout, or <code>rcon_address</code> points at the wrong server.</li> | |
| 53 | +<li><strong><code>Bad rcon server response</code></strong> — the challenge step failed, usually a firewall dropping the return packet or a NAT that rewrites the source port. Open UDP 27015 both directions.</li> | |
| 54 | +<li><strong>RCON silently does nothing</strong> — <code>rcon_password</code> is empty on the server, which disables RCON completely.</li> | |
| 55 | +<li><strong>Works locally, fails remotely</strong> — the value differs because a per-map or <code>autoexec.cfg</code> reset it after <code>server.cfg</code> ran. Grep your configs for a second <code>rcon_password</code> line.</li> | |
| 56 | +</ul> | |
| 57 | + | |
| 58 | +<h2>Verification</h2> | |
| 59 | +<p>From a client that is connected to the server, set the password and run a harmless privileged command:</p> | |
| 60 | +<pre>rcon_password "a-long-random-string-no-spaces" | |
| 61 | +rcon stats</pre> | |
| 62 | +<p>If <code>rcon stats</code> returns the server's CPU/in/out table, RCON authenticated. As a habit, do not administer day-to-day through raw RCON at all — put real admins in <a href="/tutorials/fix-admin-not-recognized">users.ini with AMXX</a> and use <a href="/plugins/csb-admin-menu">an admin menu</a> instead, so the RCON password stays a break-glass secret you rarely type.</p> |
fix-high-ping-only-my-server/en.md
A
| @@ -0,0 +1,62 @@ | ||
| 1 | +--- | |
| 2 | +title: "Fix: Everyone Has High Ping Only on My Server" | |
| 3 | +excerpt: "Players ping fine to every other server but yours? The usual culprit is low server FPS or a CPU-starved VPS, not the network. How to diagnose and fix in-game ping." | |
| 4 | +category: "errors" | |
| 5 | +tags: "ping, network" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>If every player pings 30 ms to other servers but 120 ms to yours, the problem is on your box, not the internet. In-game ping in CS 1.6 is not raw ICMP latency — it includes how long the server takes to process a tick and answer the client. A server running at a low frame rate, or one sharing a starved CPU on a cheap VPS, inflates everyone's ping equally. Work through these in order.</p> | |
| 10 | + | |
| 11 | +<h2>1. Separate real latency from server-induced ping</h2> | |
| 12 | +<p>From a player's machine, ping the server IP at the OS level:</p> | |
| 13 | +<pre>ping YOUR_SERVER_IP</pre> | |
| 14 | +<p>If OS ping is 30 ms but the in-game scoreboard shows 120 ms, the network is fine and the server is adding the other 90 ms. That points squarely at server FPS or CPU. If OS ping itself is high, it is a routing/hosting-location problem and no cvar will fix it.</p> | |
| 15 | + | |
| 16 | +<h2>2. Check the server frame rate</h2> | |
| 17 | +<p>In the server console:</p> | |
| 18 | +<pre>stats</pre> | |
| 19 | +<p>You get a line with <code>fps</code>. A healthy CS 1.6 server sits at 500 or 1000 fps on Linux, 100–200 on Windows. If <code>fps</code> is 30–64 and jittery, that alone explains inflated ping, because the server can only answer clients as fast as it ticks. On Linux, raise it:</p> | |
| 20 | +<pre>// in server.cfg | |
| 21 | +sys_ticrate 1000 | |
| 22 | +fps_max 1000</pre> | |
| 23 | +<p>Then confirm with <code>stats</code> again. If FPS refuses to climb no matter what you set, the host is the bottleneck — go to step 4.</p> | |
| 24 | + | |
| 25 | +<h2>3. Fix the update-rate caps</h2> | |
| 26 | +<p>Even at high FPS, low rate caps throttle how often the server updates each client. In <code>server.cfg</code>:</p> | |
| 27 | +<pre>sv_maxupdaterate 101 | |
| 28 | +sv_minupdaterate 30 | |
| 29 | +sv_maxrate 25000 | |
| 30 | +sv_minrate 15000</pre> | |
| 31 | +<p>Old default caps of <code>sv_maxupdaterate 30</code> feel laggy on modern connections. If clients also report <em>choke</em>, read <a href="/tutorials/fix-choke-loss-scoreboard">choke and loss on the scoreboard</a> — it is the same rate machinery.</p> | |
| 32 | + | |
| 33 | +<h2>4. Look for CPU steal on a VPS</h2> | |
| 34 | +<p>A shared VPS oversells cores. When a noisy neighbour hogs the physical CPU, your server misses ticks and ping spikes for everyone at once. On Linux:</p> | |
| 35 | +<pre>top</pre> | |
| 36 | +<p>Read the <code>%st</code> (steal) figure on the CPU line. Anything consistently above 2–3% means the hypervisor is taking cycles you paid for. Also watch <code>%id</code> (idle) drop to zero during peak hours. A game server needs a real, unshared core — if steal is high, the only fix is a better plan or a different host.</p> | |
| 37 | + | |
| 38 | +<h2>5. Rule out the route</h2> | |
| 39 | +<p>Ping being high for players from one region but fine for another is a routing problem. Have an affected player run:</p> | |
| 40 | +<pre>mtr YOUR_SERVER_IP # Linux | |
| 41 | +tracert YOUR_SERVER_IP # Windows</pre> | |
| 42 | +<p>A hop that jumps from 20 ms to 150 ms and stays there is where the latency enters. That is your provider's transit or peering — open a ticket with the trace attached.</p> | |
| 43 | + | |
| 44 | +<h2>6. Windows timer resolution</h2> | |
| 45 | +<p>On Windows, HLDS ping is sensitive to the system timer. If FPS is capped low despite <code>fps_max</code>, the machine may be running a coarse timer. Keep the server on a wired connection, disable aggressive power-saving (set the power plan to High Performance), and do not run the server on a laptop on battery — CPU throttling there tanks server FPS instantly.</p> | |
| 46 | + | |
| 47 | +<h2>7. Rule out a heavy plugin</h2> | |
| 48 | +<p>A single badly written plugin can stall the server every tick — a HUD updated on a per-frame forward, a database query run synchronously, or a heavy loop over all 32 players on every <code>PreThink</code>. The symptom is the same as CPU steal: everyone's ping climbs together, and it correlates with a specific plugin being loaded. Bisect it. Unload plugins in halves and watch <code>stats</code>:</p> | |
| 49 | +<pre>amxx pause <plugin.amxx> | |
| 50 | +stats</pre> | |
| 51 | +<p>If FPS recovers and ping drops the moment you pause one plugin, you have found the offender. Update it, replace it, or move its work off the game frame. A well-behaved server should hold its target FPS with a full slot count and every plugin loaded.</p> | |
| 52 | + | |
| 53 | +<h2>Common errors</h2> | |
| 54 | +<ul> | |
| 55 | +<li><strong>Ping fine at night, terrible at prime time</strong> — classic CPU steal on an oversold VPS. Check <code>%st</code> in <code>top</code>.</li> | |
| 56 | +<li><strong>Everyone jumps to the same high ping simultaneously</strong> — a server-wide stall (FPS drop, disk I/O, a heavy plugin), never a per-player network issue.</li> | |
| 57 | +<li><strong>Ping fine, but movement feels laggy</strong> — that is choke, not ping. See the <a href="/tutorials/fix-choke-loss-scoreboard">choke/loss guide</a>.</li> | |
| 58 | +<li><strong>One player high, everyone else fine</strong> — that player's connection or rates, not your server.</li> | |
| 59 | +</ul> | |
| 60 | + | |
| 61 | +<h2>Verification</h2> | |
| 62 | +<p>With <code>stats</code> showing stable high FPS and low CPU load, have two players from different regions connect and read the scoreboard ping. If it now tracks their OS-level ping to within ~10 ms, the server is no longer adding latency. A <a href="/plugins/csb-high-ping-kicker">high-ping kicker</a> then handles the genuinely far-away players without punishing everyone else.</p> | |
| 0 | 63 |
