The second problem was an error handling the CLOSE_WAIT/FIN_WAIT_2 state in my (and other's code), so I guess that's totally fine.
Am Samstag, 3. November 2012 um 22:22 schrieb Sebastian Staudt: > 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
