Ok here is a RCON dump of what is sent from a CSS Client to the Server: Note: This may get messed up a bit, by the email server.
(Using wrong Password) [CLIENT -> SERVER] 0000000000 12 00 00 00 02 00 00 00 03 00 00 00 50 41 53 53 ............PASS 0000000010 57 4F 52 44 00 00 WORD.. [CLIENT -> SERVER] 0000000000 11 00 00 00 01 00 00 00 02 00 00 00 22 75 73 65 ............"use 0000000010 72 73 22 00 00 rs".. [SERVER->CLIENT] 0000000000 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. [SERVER->CLIENT] 0000000000 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. [SERVER->CLIENT] 0000000000 0A 00 00 00 FF FF FF FF 02 00 00 00 00 00 .............. As far as I can see, That error Response looks like it for the "users" request. Thing is, why did it say it was sent the correct Auth password in the first response packet? And that the "users" request was ok as well, in the second response packet? And then in the third response packet, it then says that the "users" request was invalid, or is it saying that the Auth password was incorrect? Because 0x02000000 is the same as REQUEST_ID used in the AUTH Packet, and is also the same as COMMAND used in the "users" (SERVERDATA_EXECCOMMAND). (Using correct Password) [CLIENT -> SERVER] 0000000000 12 00 00 00 02 00 00 00 03 00 00 00 31 32 33 34 ............1234 0000000010 35 36 37 38 00 00 5678.. [CLIENT -> SERVER] 0000000000 11 00 00 00 00 00 00 00 02 00 00 00 22 75 73 65 ............"use 0000000010 72 73 22 00 00 rs".. [SERVER->CLIENT] 0000000000 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 .............. This looks like it's for the Auth [SERVER->CLIENT] 0000000000 27 00 00 00 00 00 00 00 00 00 00 00 3C 73 6C 6F '...........<slo 0000000010 74 3A 75 73 65 72 69 64 3A 22 6E 61 6D 65 22 3E t:userid:"name"> 0000000020 0A 30 20 75 73 65 72 73 0A 00 00 .0 users... [SERVER->CLIENT] 0000000000 0A 00 00 00 02 00 00 00 02 00 00 00 00 00 .............. Hmm, so it sends a response back, even though it already responded back with the data that we asked for? Anyone understand this? Paul Kirby > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of BrOk3R > Sent: Mon 23 August 2004 15:15 > To: [EMAIL PROTECTED] > Subject: RE: [hlds_apps] Source RCON format > > > Ok I have been testing the new rcon format and its seems like > in actual srcds version it isnt fully implemented or something. > > Here I write some of the problems I found. > > 1. Server always respond with a 10 bytes size packet. > 2. The server response for a SERVERDATA_AUTH packet always is > (rcon_password bad or good): > packet size..............10 > request id............... 0 > command.................. 0 > 3. The string response for a rcon command like 'say hello' > (after beeing well authed) is a 6 or 7 ascii strange characters. > > > > Maybe I am doing something wrong? > > Excuse my english. > > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de > BrOk3R Enviado el: lunes, 23 de agosto de 2004 13:38 > Para: [EMAIL PROTECTED] > Asunto: RE: [hlds_apps] Source RCON format > > Wop! If I send SERVERDATA_EXECCOMMAND prior SERVERDATA_AUTH > in the srcds console appear a "Bad password" message, but if > I try sending a SERVERDATA_AUTH with the good rcon_password > the server send the response 0xa. Is it wrong ? > > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de > BrOk3R Enviado el: lunes, 23 de agosto de 2004 13:21 > Para: [EMAIL PROTECTED] > Asunto: RE: [hlds_apps] Source RCON format > > I trying this rcon format with an srcds updated server and i > dont know if i doing something wrong but it doesnt work. > > What are the tcp port that I should use ? > > > -----Mensaje original----- > De: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] En nombre de > Alfred Reynolds Enviado el: lunes, 23 de agosto de 2004 3:40 > Para: [EMAIL PROTECTED]; > [EMAIL PROTECTED] > Asunto: [hlds_apps] Source RCON format > > Here is my first pass at writing a spec for the RCON format, > feel free to ask questions. > > > ---------------------------------------------------- > Source Server RCON format > > The protocol is based around command/response packets > encapsulated in a TCP/IP stream. The stream can have multiple > outstanding commands and can be extended to allow for > multiple sub-channels of data. > > The command packet format consists of: > > packet size (int) > request id (int) > command (int) > string1 (null delimited string) > string2 (null delimited string) > > > The packet size is the number of bytes from the start of the > requestid to the end of string2 (including the null byte). It > must be at least 10. > > Request id can be any value except for -1 (0xffffffff), it is > used by the client to de-multiplex outstanding command responses. > > Command must be: > SERVERDATA_EXECCOMMAND = 2 > or SERVERDATA_AUTH = 3 > > The meaning of the string values depends upon the command issued. > SERVERDATA_AUTH: > string1 is the rcon_password for the server. > string2 must be null (""); > > SERVERDATA_EXECCOMMAND: > string1 is the command to run. > string2 must be null (""); > > > For RCON connections the first command must be a > SERVERDATA_AUTH command. If a SERVERDATA_EXECCOMMAND command > is sent prior to successful authentication then a > SERVERDATA_AUTH_RESPONSE response packet with the failure > condition is sent (see the response section for details). > > > The response packet is the same as the command packet, which > is: packet size (int) request id (int) command response (int) > string1 (null delimited string) string2 (null delimited string) > > with valid command responses being: > SERVERDATA_RESPONSE_VALUE = 0 > or SERVERDATA_AUTH_RESPONSE = 2 > > > SERVERDATA_AUTH_RESPONSE is sent in response to a > SERVERDATA_AUTH command (or to a SERVERDATA_EXECCOMMAND > command if the connection is not successfully > authenticated). Both strings are set to null. If the request > id is -1 (0xffffffff) then the authentication attempt failed > (due to a bad password). If the request id is the same value > as sent in the command (i.e the value was mirrored back) > then authentication was successful. Any other request id is > an error and the SERVERDATA_AUTH command should be resent. > > SERVERDATA_RESPONSE_VALUE is sent in response to a > SERVERDATA_EXECCOMMAND command. string1 contains the response > to the command and string2 is null (""). string1 is at most > 4096 characters, so a single SERVERDATA_EXECCOMMAND command > may result in multiple SERVERDATA_RESPONSE_VALUE response packets. > > > > > > _______________________________________________ > hlds_apps mailing list > [EMAIL PROTECTED] > http://list.valvesoftware.com/mailman/listinfo> /hlds_apps > > > > _______________________________________________ > > hlds_apps mailing list > [EMAIL PROTECTED] > http://list.valvesoftware.com/mailman/listinfo> /hlds_apps > > > > _______________________________________________ > > hlds_apps mailing list > [EMAIL PROTECTED] > http://list.valvesoftware.com/mailman/listinfo> /hlds_apps > > > > _______________________________________________ > > hlds_apps mailing list > [EMAIL PROTECTED] > http://list.valvesoftware.com/mailman/listinfo> /hlds_apps > _______________________________________________ hlds_apps mailing list [EMAIL PROTECTED] http://list.valvesoftware.com/mailman/listinfo/hlds_apps
