Romania XPlayZM.CSBlackDevil.COM # Zombie Plague UltimateX [ Respawn + FDL + VIP 22-12PM + POINTS] ® 26/32
Unknown ❤ RESPAWN.ZAFEST.RO | VIP FREE | FREE FOR ALL ❤ 0/32
Germany ELITE.WORLDCS.RO # [SKINS |VIP + REVIVE| RANKS] 16/32
Promocionar servidor

Add 3 tutorials (3 files)

Browse Source
Daemon666 committed parent 36af6df236 commit ccf49ec9a709750517652a07bc5220681eb11e19
3 changed files with 186 additions and 0 deletions
+70 -0 cs16-server-firewall-ports/en.md A
@@ -0,0 +1,70 @@
1 +---
2 +title: "Which Ports to Open for a CS 1.6 Server (UDP 27015, 26900, 27020)"
3 +excerpt: "The exact ports a CS 1.6 server uses — game, RCON, HLTV, and Steam master traffic — with copy-paste ufw and iptables rules and how to prove the port is really open."
4 +category: "installation"
5 +tags: "firewall, ports"
6 +image: ""
7 +read_time: "8 min read"
8 +---
9 +<p>CS 1.6 firewalling confuses people because the game is UDP but RCON is TCP on the same port number, and because "open the port" on a VPS means two different things — the host firewall and the provider's network filter. This is the complete, minimal port list, why each one exists, and how to confirm it is genuinely reachable from outside.</p>
10 +
11 +<h2>The ports that matter</h2>
12 +<table>
13 +<thead><tr><th>Port</th><th>Protocol</th><th>Direction</th><th>Purpose</th></tr></thead>
14 +<tbody>
15 +<tr><td>27015</td><td>UDP</td><td>Inbound</td><td>Game traffic and Steam A2S queries. The one non-negotiable port.</td></tr>
16 +<tr><td>27015</td><td>TCP</td><td>Inbound</td><td>RCON. Same number as the game, different protocol.</td></tr>
17 +<tr><td>27020</td><td>UDP</td><td>Inbound</td><td>HLTV / SourceTV, if you run a spectator proxy. Default; configurable.</td></tr>
18 +<tr><td>26900</td><td>UDP</td><td>Inbound</td><td>Legacy client/query port range some setups use. Harmless to allow.</td></tr>
19 +<tr><td>27011 / 27015-27016</td><td>UDP</td><td>Outbound</td><td>Heartbeats to the Steam master servers. Needs outbound UDP, not inbound.</td></tr>
20 +</tbody>
21 +</table>
22 +<p>For a single default server, the honest minimum is <strong>UDP 27015 inbound</strong> (game) and <strong>TCP 27015 inbound</strong> (RCON). Everything else is situational.</p>
23 +
24 +<h2>1. UDP is the game; do not forget it</h2>
25 +<p>All gameplay — movement, shooting, the A2S query that populates the server browser — is UDP 27015. If only TCP is open, the server browser shows nothing and no one connects. This is the mistake people make when they reuse a web-server firewall template that only thinks in TCP.</p>
26 +
27 +<h2>2. RCON is TCP on the same number</h2>
28 +<p>Remote console uses a TCP connection to the same port number as the game. So a fully working server needs both <code>27015/udp</code> and <code>27015/tcp</code> open. If players connect fine but your web-based RCON tool times out, TCP 27015 is closed.</p>
29 +
30 +<h2>3. ufw (Ubuntu / Debian)</h2>
31 +<pre>sudo ufw allow 27015/udp
32 +sudo ufw allow 27015/tcp</pre>
33 +<p>Running <a href="/tutorials/multiple-cs16-servers-one-vps">several servers</a>? Open the whole range:</p>
34 +<pre>sudo ufw allow 27015:27020/udp
35 +sudo ufw allow 27015:27020/tcp</pre>
36 +<p>Check the result:</p>
37 +<pre>sudo ufw status numbered</pre>
38 +
39 +<h2>4. iptables (no ufw)</h2>
40 +<pre>sudo iptables -A INPUT -p udp --dport 27015 -j ACCEPT
41 +sudo iptables -A INPUT -p tcp --dport 27015 -j ACCEPT
42 +# for a range of servers:
43 +sudo iptables -A INPUT -p udp --dport 27015:27020 -j ACCEPT
44 +sudo iptables -A INPUT -p tcp --dport 27015:27020 -j ACCEPT</pre>
45 +<p>Persist the rules with <code>iptables-save</code> or your distro's <code>netfilter-persistent</code> so they survive a reboot — a firewall that forgets its rules on restart is a classic "it worked yesterday" report.</p>
46 +
47 +<h2>5. Outbound must be allowed too</h2>
48 +<p>To show up in the internet list the server heartbeats the Steam master servers, which is <strong>outbound</strong> UDP. Most firewalls allow outbound by default, but a locked-down egress policy will silently keep your server off the list even though clients can connect by direct IP. If direct <code>connect</code> works but the server never lists, check egress before you blame <code>sv_lan</code>. (Also confirm <code>sv_lan 0</code> — see <a href="/tutorials/hlds-command-line-parameters">the parameters guide</a>.)</p>
49 +
50 +<h2>6. HLTV and extra query ports</h2>
51 +<p>If you run an HLTV/SourceTV spectator proxy, it binds its own UDP port — 27020 by default — and that port needs to be open inbound for spectators to connect, exactly like the game port. It is a separate listener from the game server, so opening 27015 does nothing for it. If you moved HLTV to another port, open the number you actually configured, not the default.</p>
52 +
53 +<h2>7. The provider firewall is separate</h2>
54 +<p>On a cloud VPS there are often two firewalls: the OS (ufw/iptables) and the provider's security group / network filter in their control panel. Opening ufw does nothing if the provider still blocks inbound UDP. Some budget hosts block or rate-limit UDP by default specifically because of game-server abuse — check the provider panel, and if UDP is filtered, that is why nothing connects no matter what you do on the box.</p>
55 +
56 +<h2>Common errors</h2>
57 +<ul>
58 +<li><strong>Server in list, but nobody can connect (or vice versa)</strong> — you opened TCP but not UDP. Gameplay and browser queries are UDP; open <code>27015/udp</code>.</li>
59 +<li><strong>Players connect, RCON times out</strong> — TCP 27015 is closed. Open it.</li>
60 +<li><strong>Direct connect works, server never lists</strong> — outbound UDP to the master is blocked, or <code>sv_lan 1</code>. Allow egress and set <code>sv_lan 0</code>.</li>
61 +<li><strong>Works until reboot</strong> — iptables rules were not persisted. Save them.</li>
62 +<li><strong>ufw open, still unreachable</strong> — the provider's network firewall is blocking UDP. Fix it in their panel.</li>
63 +</ul>
64 +
65 +<h2>Verification</h2>
66 +<p>First confirm the server is actually bound locally:</p>
67 +<pre>ss -lunp | grep 27015</pre>
68 +<p>Then test reachability from <em>outside</em> the box — a firewall test from the server itself proves nothing. From another machine, probe UDP 27015:</p>
69 +<pre>nmap -sU -p 27015 YOUR_SERVER_IP</pre>
70 +<p>An <code>open</code> or <code>open|filtered</code> result with a valid A2S response means the port is reachable. The definitive test is still a client: <code>connect YOUR_IP:27015</code>. If that works and the server also appears in the internet list, every port that matters is open. Next, lock the launch and ports into a <a href="/tutorials/hlds-systemd-service">systemd service</a>.</p>
+49 -0 fix-duplicate-steamids-nonsteam/en.md A
@@ -0,0 +1,49 @@
1 +---
2 +title: "Fix: All Non-Steam Players Get the Same SteamID (VALVE_ID_LAN)"
3 +excerpt: "When every non-Steam player shares one id, admin access and bans by SteamID collapse. Fix it with sv_lan 0 and a correct Reunion SteamIdHashSalt and client-id modes."
4 +category: "errors"
5 +tags: "steamid, reunion"
6 +image: ""
7 +read_time: "8 min read"
8 +---
9 +<p>If <code>status</code> shows every non-Steam player carrying <code>VALVE_ID_LAN</code>, or the same <code>STEAM_ID_LAN</code>, your entire admin and ban system is broken — because AMX Mod X keys admin flags and bans on the unique id. When everyone shares one id, banning one player bans them all, and granting one admin grants everyone. This is not a plugin bug; it is an authentication configuration problem, and it has two usual causes.</p>
10 +
11 +<h2>1. sv_lan 0 first</h2>
12 +<p>The engine only issues real ids to internet clients. With <code>sv_lan 1</code>, every client — Steam or not — is stamped <code>VALVE_ID_LAN</code> because the server believes it is on a LAN where authentication is pointless. This alone produces the exact "everyone has the same id" symptom. In <code>server.cfg</code> and on the command line:</p>
13 +<pre>sv_lan 0</pre>
14 +<p>Restart fully and re-check <code>status</code>. If the shared id was <code>VALVE_ID_LAN</code> specifically, this is very often the whole fix.</p>
15 +
16 +<h2>2. Give non-Steam clients a source of unique ids</h2>
17 +<p>Steam clients get their id from Steam. Non-Steam clients have no Steam id to present, so <strong>something on the server must derive a stable, unique id for each of them</strong> — that is <a href="/tutorials/install-reunion">Reunion</a> on ReHLDS (or <a href="/tutorials/install-dproto">dproto</a> on original HLDS). If that component is missing or misconfigured, non-Steam clients collapse onto a single fallback id. If non-Steam players cannot even connect, solve that first in <a href="/tutorials/fix-nonsteam-players-cant-join">non-Steam players can't join</a>; this guide assumes they connect but share an id.</p>
18 +
19 +<h2>3. The salt is what makes the id unique and stable</h2>
20 +<p>Reunion derives each non-Steam player's <code>STEAM_x:y:z</code> from their client identity plus your <code>SteamIdHashSalt</code>. Two rules follow:</p>
21 +<ul>
22 +<li>The salt must be <strong>at least 16 characters</strong>, or Reunion refuses to load and you fall back to a single shared id.</li>
23 +<li>The salt must be <strong>set and never changed</strong>. If it is empty, ids are not properly individualised; if you change it, every non-Steam id changes at once, wiping admin and bans.</li>
24 +</ul>
25 +<pre>SteamIdHashSalt = 8f3Kd92lasQ7zXcV19mT</pre>
26 +<p>Set a random 16+ character value once, back it up, and leave it alone.</p>
27 +
28 +<h2>4. Check the client-id modes</h2>
29 +<p>Reunion's <code>cid_*</code> options decide how each client type is turned into an id. A misconfiguration here can route several client types onto the same generated id even with a good salt. Start from the shipped defaults and change them only when you understand each mode — the <a href="/tutorials/install-reunion">Reunion guide</a> documents what each does. The goal is that revemu/steam-emulated clients each yield their <em>own</em> stable <code>STEAM_x:y:z</code>, not a shared one.</p>
30 +
31 +<h2>5. Why this matters to admin and bans</h2>
32 +<p>AMX Mod X can key admin access to either an id or a name+password, and it keys bans to the unique id. If you run id-based admins, your <code>addons/amxmodx/configs/users.ini</code> entries look like this:</p>
33 +<pre>"STEAM_0:1:12345678" "" "abcdefghijklmnopqrstu" "ce"</pre>
34 +<p>The first field is the authid. When every non-Steam player collapses onto one shared id, that single line grants — or bans — all of them at once. This is why the symptom shows up as "I banned one cheater and half the server vanished", or "I gave one friend admin and now everyone has it". The moment ids become unique and stable, both <code>amx_ban</code> by id and id-based <code>users.ini</code> entries behave correctly again. Check who is who live with:</p>
35 +<pre>amx_who</pre>
36 +<p>which prints each connected player's name, authid and access flags — the fastest way to confirm every player now carries a distinct id.</p>
37 +
38 +<h2>Common errors</h2>
39 +<ul>
40 +<li><strong>Everyone is <code>VALVE_ID_LAN</code></strong> — <code>sv_lan 1</code>. Step 1.</li>
41 +<li><strong>Everyone is the same <code>STEAM_ID_LAN</code> despite <code>sv_lan 0</code></strong> — no working non-Steam auth provider, or Reunion failed to load because the salt is too short.</li>
42 +<li><strong>Ids were unique, then all changed on the same day</strong> — someone changed <code>SteamIdHashSalt</code>. There is no recovery for the old ids other than restoring the previous salt; keep a backup of it.</li>
43 +<li><strong>Steam players fine, non-Steam share an id</strong> — Reunion loaded but the <code>cid_*</code> modes are collapsing client types. Step 4.</li>
44 +</ul>
45 +
46 +<h2>Verification</h2>
47 +<p>Get two different non-Steam players (or two non-Steam clients on different machines) connected at once and run:</p>
48 +<pre>status</pre>
49 +<p>The <code>uniqueid</code> column must show <strong>two different</strong> <code>STEAM_x:y:z</code> values — not <code>VALVE_ID_LAN</code>, not the same id twice. Then have one of them disconnect and reconnect: their id must be <strong>the same</strong> as before, proving it is stable across sessions (which is what makes bans and admin persist). Distinct ids per player, stable across reconnects, means the fix holds and your admin/ban system will behave again.</p>
+67 -0 fix-metamod-bad-load/en.md A
@@ -0,0 +1,67 @@
1 +---
2 +title: "Fix: 'Bad load' in meta list (Metamod Plugin Fails)"
3 +excerpt: "A Metamod plugin shows 'bad load' in meta list. What that status means, the real causes — wrong architecture, ABI mismatch, wrong path or platform tag — and how to fix each."
4 +category: "errors"
5 +tags: "metamod, bad-load"
6 +image: ""
7 +read_time: "7 min read"
8 +---
9 +<p>You run <code>meta list</code> and a plugin sits there as</p>
10 +<pre>bad load</pre>
11 +<p>instead of <code>RUN</code>. "Bad load" is Metamod telling you it found the file, tried to load it as a Metamod plugin, and the operating system or Metamod itself rejected it. It is not "file missing" (that is <code>file open error</code>) — the file is there, but it is the wrong kind of file, the wrong architecture, or built against an incompatible interface. Here is how to tell which.</p>
12 +
13 +<h2>1. Read the exact status</h2>
14 +<p>Get the full picture, not just the summary line:</p>
15 +<pre>meta list</pre>
16 +<p>Note the plugin's status and the path Metamod loaded it from. The path matters — a wrong or stale path is a common cause, and Metamod prints exactly what it tried.</p>
17 +
18 +<h2>2. Wrong architecture (the most common cause)</h2>
19 +<p>Everything in a CS 1.6 server is 32-bit. A 64-bit <code>.so</code>/<code>.dll</code> loads as <code>bad load</code> every time. Check it on Linux:</p>
20 +<pre>file addons/amxmodx/dlls/amxmodx_mm_i386.so</pre>
21 +<p>It must report:</p>
22 +<pre>ELF 32-bit LSB shared object, Intel 80386</pre>
23 +<p>If it says <code>x86-64</code>, you downloaded or built the wrong file. Get the 32-bit build. A missing 32-bit dependency has the same effect — the loader cannot resolve the library, so Metamod reports the load as bad. Check what it needs:</p>
24 +<pre>ldd addons/amxmodx/dlls/amxmodx_mm_i386.so</pre>
25 +<p>Any <code>not found</code> line is a 32-bit library you must install; see <a href="/tutorials/install-cs16-dedicated-server-linux-steamcmd">the 32-bit library setup</a>.</p>
26 +
27 +<h2>3. ABI / version mismatch after an engine switch</h2>
28 +<p>This is the classic post-migration failure: you moved to <a href="/tutorials/install-rehlds-on-linux">ReHLDS</a> and now old Metamod plugins show <code>bad load</code>. Classic Metamod-P and very old plugins predate the ReHLDS/Metamod-r ABI. The fix is to move to <a href="/tutorials/install-metamod-r">Metamod-r</a> and use plugin builds compatible with it. If you are unsure which loader you have, <a href="/tutorials/metamod-r-vs-metamod-p">Metamod-r vs Metamod-P</a> explains how to tell and why it matters.</p>
29 +
30 +<h2>4. Wrong platform tag or path in plugins.ini</h2>
31 +<p>Metamod's plugin list is <code>addons/metamod/plugins.ini</code>. Each line is tagged by platform:</p>
32 +<pre>linux addons/amxmodx/dlls/amxmodx_mm_i386.so
33 +win32 addons\amxmodx\dlls\amxmodx_mm.dll</pre>
34 +<p>Two failure modes here: a config copied from a Windows server lists <code>.dll</code> paths that do not exist on Linux (and vice versa), and a line with the right platform tag but a wrong or old filename. On Linux the file is case-sensitive — <code>amxmodx_mm_i386.so</code> is not <code>AMXModX_mm_i386.so</code>.</p>
35 +
36 +<h2>5. It is not actually a Metamod plugin</h2>
37 +<p>People sometimes list an AMXX <em>plugin</em> (<code>.amxx</code>) or a module in <code>metamod/plugins.ini</code>. Only Metamod plugins (AMXX itself, Reunion, ReAPI, etc.) belong there. An <code>.amxx</code> goes in AMXX's <code>plugins.ini</code>, not Metamod's — see <a href="/tutorials/install-amxx-plugin-files">installing an AMXX plugin</a>. A file that is not a Metamod plugin loads as <code>bad load</code>.</p>
38 +
39 +<h2>Common errors</h2>
40 +<ul>
41 +<li><strong><code>bad load</code></strong> — wrong architecture, missing 32-bit dependency, ABI mismatch, or a non-Metamod file. Work through the sections above.</li>
42 +<li><strong><code>file open error</code></strong> (different status) — the path in <code>plugins.ini</code> does not point at an existing file. Fix the path, not the binary.</li>
43 +<li><strong>Plugin loads on Windows, <code>bad load</code> on Linux</strong> — you kept the <code>win32</code> path or copied a <code>.dll</code>. Use the <code>linux</code> line and the <code>.so</code>.</li>
44 +<li><strong>All plugins <code>bad load</code> after moving to ReHLDS</strong> — old Metamod. Switch to Metamod-r.</li>
45 +</ul>
46 +
47 +<h2>Verification</h2>
48 +<p>After the fix, restart or change the map and re-check:</p>
49 +<pre>meta list</pre>
50 +<p>Every plugin must read <code>RUN</code>. For AMXX specifically, confirm the chain continued to load:</p>
51 +<pre>amxx version
52 +amxx plugins</pre>
53 +<p>If Metamod shows AMXX as <code>RUN</code> and <code>amxx version</code> answers, the loader problem is gone. A plugin that still reports <code>bad load</code> after you have confirmed 32-bit architecture, resolved dependencies and correct <code>plugins.ini</code> tagging is built against an interface your Metamod does not provide — replace it with a build made for your Metamod-r version.</p>
54 +
55 +<h2>Decision table: which cause is yours</h2>
56 +<p>Every <code>bad load</code> is one of a small set of causes. Run <code>file</code> and <code>ldd</code> once and this table resolves it:</p>
57 +<table>
58 +<thead><tr><th>What you observe</th><th>Cause</th><th>Fix</th></tr></thead>
59 +<tbody>
60 +<tr><td><code>file</code> says x86-64</td><td>Wrong architecture</td><td>Get the 32-bit (i386) build</td></tr>
61 +<tr><td><code>ldd</code> shows <code>not found</code></td><td>Missing 32-bit library</td><td>Install lib32gcc-s1 / lib32stdc++6 / libc6:i386</td></tr>
62 +<tr><td>32-bit, deps resolve, still bad load</td><td>ABI mismatch</td><td>Move to Metamod-r + matching plugin build</td></tr>
63 +<tr><td>All plugins bad load after engine swap</td><td>Old Metamod vs ReHLDS</td><td>Switch to Metamod-r</td></tr>
64 +<tr><td>Only after copying a config from another box</td><td>Wrong platform tag / path</td><td>Fix the win32/linux line in plugins.ini</td></tr>
65 +</tbody>
66 +</table>
67 +<p>The reason this matters: "bad load" reads like one error but is really five, and people waste hours reinstalling a perfectly good plugin when the actual fault was a 64-bit download or a <code>win32</code> line on a Linux box. Two commands — <code>file</code> and <code>ldd</code> — eliminate the two most common causes in under a minute, and only when both pass are you actually looking at an interface-version problem that needs a different build of the plugin itself.</p>
0 68