Drahkar Posted March 5 Author Report Posted March 5 (edited) 2 hours ago, Shijikori said: Hey! Just letting you know I updated Vintage RCON to fix an issue with packet handling. Please make sure that your web console is compatible with the classic handling that was reimplemented in the new version! I overlooked this when I checked the changes submitted by Taehan. Every command packet should now receive only one packet of response. Please ensure that your console sends a SERVERDATA_RESPONSE_VALUE (packet type 0) after receiving the first response to a command. The server should respond with an empty serverdata response packet if there are no more chunks left to the response. Feel free to communicate with me through Discord (@shijikori) if you need technical details Refer to Valve's documentation to validate your rcon web console's client behaviour : https://developer.valvesoftware.com/wiki/Source_RCON_Protocol @Shijikori Thanks for the heads up! I'll update the version and test. I actually suspect that may have been the cause of a id count error I was running into that ultimately had me change to an async call through the python rcon library. I'll let you know! Edited March 5 by Drahkar
Shijikori Posted March 5 Report Posted March 5 @Drahkar that's not impossible. The rework's behaviour was to spam the client with all the chunks of the response at once. I identified that problem while testing the mod on 1.22 pre-release. Assuming the python library sent the type 0 packet with a different id than the command which would then cause that id error because it would simply happen to receive the spammed packet after requesting another chunk (which would have the previous id instead of the id selected by the client for the request). RCON clients are not expecting to receive more than a single packet per packet they send. That behaviour causes issues with clients who behave based on common specification. I was testing using ARRCON, with the small changes in version 2.0.1, ARRCON no longer had the issue where sometimes it would seemingly get no response from the server despite the command actually being passed through.
Shijikori Posted March 6 Report Posted March 6 You should include in your security best practices a mention about RCON being unencrypted. That is by the specification, I recommend, myself, to never expose the RCON connectivity to untrusted networks. Your web console should be preferred if possible (and with certificates, especially over the internet). The RCON password could feasibly be snooped on an untrusted network or the internet, making a server vulnerable to griefing and anything else possible with console administrator access of a Vintage Story server software. The RCON access should always be used with necessary precautions, be it restricting access to only the local host (requiring a more secure connection first, such as SSH, to then interact with the server via an RCON client) or using a VPN setup such as wireguard or IPsec to ensure connectivity between RCON client and the server is encrypted.
Drahkar Posted March 6 Author Report Posted March 6 (edited) @Shijikori That is a solid recommendation. The standard configuration for the server has RCON only accessible through the WebUI, but calling it out is definitely a valid point. I should also look into updating the process for handling the WebUI to also support using Let's Encrypt, so it will just natively support SSL, and then give them a way to deploy it with their own certs, if that is what is preferred. I've opened Github Issue #65 for implementing a solution that will allow for simple automated support, if they are using anything more than localhost access. Edited March 6 by Drahkar Expanded on solution. 1
Shijikori Posted March 7 Report Posted March 7 @Drahkar Another minor update, though I'll be done for a while following that one. Version 2.0.2 of Vintage RCon improves logging and leaves more verbose traces for administrators. This can be very useful to know what the rcon connection was used for in the logs. The full command is now part of the logs (including arguments) as well as the address of the client which sent it. Nothing changed in terms of logic and processing, so it shouldn't cause any issues if version 2.0.1 didn't give you any problems. 1
Drahkar Posted March 11 Author Report Posted March 11 On 3/7/2026 at 12:52 PM, Shijikori said: @Drahkar Another minor update, though I'll be done for a while following that one. Version 2.0.2 of Vintage RCon improves logging and leaves more verbose traces for administrators. This can be very useful to know what the rcon connection was used for in the logs. The full command is now part of the logs (including arguments) as well as the address of the client which sent it. Nothing changed in terms of logic and processing, so it shouldn't cause any issues if version 2.0.1 didn't give you any problems. @Shijikori Perfect. I'll make sure future builds leverage 2.0.2. I've already confirmed everything in place works with the new version, so it looks good. For anyone waiting on 1.22.0-rc.*, I'm sourcing your opinion. Currently, I'm seeing a pretty consistent failure when you have more than one Mod loaded on the dedicated server. The client gets a bad request error when trying to communicate with ModDB. I've been holding off making the build, due to that error. Would you all like me to build it anyway? NOTE: ALWAYS backup your saves before doing any upgrade. I've seen a few posts of people being burned because of that. 2
Drahkar Posted March 28 Author Report Posted March 28 With the ModDB error verified to have been fixed, I've published 1.22.0-rc.5. I hope everyone finds it interesting. I plan to dig into it more, as well. I will be offline until April 7th, so if the next RC drops before then, I'll take care of it, as soon as I get back. Docker Hub: ralnoc/vintagestory ralnoc/vintagestory:1.21.6 ralnoc/vintagestory:1.22.0-rc.5 GitHub Container Registry: ghcr.io/darkmatterproductions/vintagestory ghcr.io/darkmatterproductions/vintagestory:1.21.6 ghcr.io/darkmatterproductions/vintagestory:1.22.0-rc.5
Jarfi Posted April 15 Report Posted April 15 I'm getting major errors with this dockerfile and permissions on the data folder which result in messages about 'invalid user password' data folder defaults to uid/gid 1100
Drahkar Posted April 21 Author Report Posted April 21 On 4/15/2026 at 5:11 PM, Jarfi said: I'm getting major errors with this dockerfile and permissions on the data folder which result in messages about 'invalid user password' data folder defaults to uid/gid 1100 The container runs using a user assigned the UID:GID of 1100:1100. As long as you have the directory you are mounting owned by that, and given proper write permissions, you should be set. Running : chmod -R 1100:1100 /path/to/data/directory will set ownership correctly. Can you detail how you are running it? It might help with offering suggestions.
Drahkar Posted April 21 Author Report Posted April 21 It seems 1.22.0 has dropped as stable! I will be getting the image built and deployed, tonight!
Drahkar Posted April 21 Author Report Posted April 21 He were go! Vintage Story 1.22.0, fresh off the presses! The latest tag will also pick up 1.22.0 from now on. Docker Hub: ralnoc/vintagestory ralnoc/vintagestory:1.22.0 GitHub Container Registry: ghcr.io/darkmatterproductions/vintagestory ghcr.io/darkmatterproductions/vintagestory:1.22.0 IMPORTANT!! Always remember to backup your data files, before you do any kind of upgrade. Not all Mods are compatible with 1.22.0 yet.
Recommended Posts