Hi, there are three (maybe related) problems with Source's RCON protocol implementation that make it very hard to handle authentication problems. As some of you might know, I'm the developer of the Steam Condenser library which has a RCON implementation. In the last weeks I got multiple bug reports about odd RCON behavior.
The first problem is pretty annoying and occurs since a few weeks (or months?) ago. When using an unauthenticated connection, without sending a correct SERVERDATA_AUTH first, SrcDS will respond with an empty SERVERDATA_RESPONSE_VALUE instead of SERVERDATA_AUTH_RESPONSE. This is in conflict with the only available documentation on VDC (https://developer.valvesoftware.com/wiki/RCON#SERVERDATA_AUTH_RESPONSE) which my (and probably all other implementations) are based on. The second problem occurs when resetting the password while one or more RCON clients have open and authenticated connections. Using rcon_password will cause every TCP connection to be closed on the server side, i.e. not reset completely. It's ugly to detect such a situation and should be handled differently. Changing the RCON password should invalidate all connections by either resetting the TCP connection or replying to all further requests with SERVERDATA_AUTH_RESPONSE. Resetting the password usually happens while the map changes, which is pretty annoying to my users. The third problem might be the biggest. Banning a client (at least by IP with addip) does not immediately invalidate the RCON connection of that client. Existing connections can be used to send commands to the server! Only new connections are blocked, i.e. you'll get a ECONNRESET. The behavior should be identical to changed RCON passwords. PS: While discussing downsides of the RCON protocol: RCON replies, e.g. of commands like cvarlist, should be cleanly terminated. There's a workaround for this problem (https://developer.valvesoftware.com/wiki/RCON#Multiple-packet_Responses), but it's pretty hackish and overly complicated. One clean termination sequence per response would be great. Best regards, Sebastian
_______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds
