Difference between revisions of "RCON"
Barneygale (talk | contribs) (Created page with "Rcon is a protocol introduced in 1.9pre4 for the purpose of remote administration of a server. == Server Config == enable-rcon=true rcon.password=<your password> == Pa...") |
Barneygale (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | + | RCON is a protocol introduced in 1.9pre4 for the purpose of remote administration of a server. It's basically a shitty implementation of the Source RCON protocol [http://developer.valvesoftware.com/wiki/Source_RCON_Protocol] | |
| − | + | ||
== Server Config == | == Server Config == | ||
| Line 10: | Line 10: | ||
Integers are little-endian, in contrast with the [[Protocol|Beta protocol]]. | Integers are little-endian, in contrast with the [[Protocol|Beta protocol]]. | ||
| − | You should generate a new | + | You should generate a new request ID for every packet you send. This allows you to match up incoming packets (responses) with what you sent. |
| − | In the event of an auth failure (i.e. your login is incorrect, or you're trying to send commands without first logging in), | + | In the event of an auth failure (i.e. your login is incorrect, or you're trying to send commands without first logging in), request ID will be set to <code>-1</code> |
{| class="wikitable" | {| class="wikitable" | ||
| Line 24: | Line 24: | ||
| Length of ''remainder'' of packet | | Length of ''remainder'' of packet | ||
|- | |- | ||
| − | | | + | | Request ID |
| int | | int | ||
| − | | Client-generated | + | | Client-generated ID |
|- | |- | ||
| − | | | + | | Type |
| int | | int | ||
| <code>3</code> for login, <code>2</code> to run a command | | <code>3</code> for login, <code>2</code> to run a command | ||
| Line 47: | Line 47: | ||
Outgoing payload: password. | Outgoing payload: password. | ||
| − | If the server returns a packet with the same ID, auth was successful. If you get an ID of -1, auth failed (wrong password). | + | If the server returns a packet with the same request ID, auth was successful (note: packet type is 2, not 3). If you get an request ID of -1, auth failed (wrong password). |
=== 2: Command === | === 2: Command === | ||
Revision as of 14:47, 14 October 2011
RCON is a protocol introduced in 1.9pre4 for the purpose of remote administration of a server. It's basically a shitty implementation of the Source RCON protocol [1]
Contents
Server Config
enable-rcon=true rcon.password=<your password>
Packet Format
Integers are little-endian, in contrast with the Beta protocol.
You should generate a new request ID for every packet you send. This allows you to match up incoming packets (responses) with what you sent.
In the event of an auth failure (i.e. your login is incorrect, or you're trying to send commands without first logging in), request ID will be set to -1
| Field name | Field Type | Notes |
|---|---|---|
| Length | int | Length of remainder of packet |
| Request ID | int | Client-generated ID |
| Type | int | 3 for login, 2 to run a command
|
| Payload | byte[] | ASCII text |
| 2-byte pad | byte, byte | Two null bytes |
Packets
3: Login
Outgoing payload: password.
If the server returns a packet with the same request ID, auth was successful (note: packet type is 2, not 3). If you get an request ID of -1, auth failed (wrong password).
2: Command
Outgoing payload should be the command to run, e.g. time set 0
Incoming payload is the output of the command, though many commands return nothing, and there's no way of detecting unknown commands.
Implementation details
Maximum request length: 1460 (giving a max payload length of 1446)
Code exists in the notchian server to split large responses (>4096 bytes) into multiple smaller packets. However, the code that actually encodes each packet expects a max length of 1248, giving a max return payload length of 1234 bytes.
Example implementations
- https://github.com/barneygale/MCRcon (python, basic, synchronous)
