`single_packet` / `-1` is undocumented, has confusing defaults, can't be turned off for non-config-file usage

[wisq]

I was trying to use this with a Minecraft server (which doesn't support multi-packet and just hangs the connection if you try it), and was having trouble translating between the fully command line rcon -H host -p port -P password usage and the config file rcon -s name usage — the former worked fine, the latter would hang, even with the exact same host/port/password settings.

Dug into the code and discovered the (undocumented) single_packet=true / -1 option. It seems like this defaults to true for command line usage (with no way to turn it off?), yet defaults to false for config file usage.

If setting the default to true is the intent, then it's pretty easy to do that — see https://github.com/wisq/rcon/commit/de3685ecab731afc2e55bb78fb894879d6010a4e — but there should probably be an option to turn it off for the command line, and it should be added to the manpage. I could certainly look at adding those and submitting a PR, but I wanted to check whether the "default to single packet mode" approach was indeed the intent going forward.

[n0la]

The whole idea around "single packet mode" in general was a dumb idea, since no other srcrcon servers apart from those made by Valve are capable of handling the multi packet mode.

On master, single packet mode was enabled by default, and the option -1 and --1packet simply do nothing any more. They were kept to allow for backward compatibility, and to not break other people's scripts.

So in theory, on the master branch, your minecraft server should be supported by default without giving any weird flags on either the command-line, or in the config file.

What version are you using?

[wisq]

Ah, fair enough re: semantics and documentation and etc.

For my issue, I was compiling the client straight from the master branch. The issue is that the config file actually does default to false if the single_packet option isn't specified, since it explicitly sets *single_packet_mode = (single_packet == TRUE);, and single_packet is not equal to TRUE if it's entirely absent from the configuration.

My solution (per the linked commit, above) was just to set it to true if either the option was set and true, or if it was not set at all (error != NULL). I'm not sure if that's the most elegant way to handle it, but it did work for me.

[n0la]

I see the problem. Single packet mode should definitely be obsoleted from the configuration as well. I will get to it tomorrow. Thanks for bringing this to my attention.

[n0la]

Can you try the recent master? I decided to remove the entire code related to "single" and "multi" packet mode. Single packet mode should now be the sane default.

[butaford]

Sorry, maybe I need to create a separate ticket. When connecting to CSS: ./rcon -1 -H 172.17.1.66 -p 27015 -P RCONPASS status an error occurs: Invalid auth reply, valid password? When using the configuration file:

[csspub]
hostname = 192.168.0.2
port = 27015
password = RCONPASS
#single_packet = true

./rcon -c /path/to/config/example/rconrc -s csspub status server answers correctly, no errors

sorry bad eng

[n0la]

Please make a separate ticket. If your password contains special characters (like $ or !) you need to do proper shell escaping.

[n0la]

I am pretty sure that this is now fixed as well, since I officially dropped single packet mode in the newest version. The option is still there to not break current scripts, but it doesn't do anything any more, and the code works either way.

[martin8883]

Hi,

decided to use this thread because it seems not to be fixed. I am also trying to connect a minecraft server (don´t mind the avorion hostname), MC replies with one packet but rcon does not proceed. Will there be any more patching or should we use another tool for MC?

Regards Martin