Does not match expected packet size about mcrcon

[IIPoliII]

Same for me i have no idea what is due too

[IIPoliII]

The fix was easy simply fork it and do this joinandplaycoop@30c39b7 (of course putting your desired packet size)

[Tiiffi]

@keke1229488344

Sometimes when I type the help command（ ./mcrcon -p "password" -H IP -P Port "help"）, it returns "Warning: recv() return value (1408) does not match expected packet size (3133)."

What Minecraft server version you are using?

[northkill]

I'm having this issue too. My server is Spigot for Minecraft version 1.14.4.

In addition, the failing command is especially /help. I couldn't test every command, but other commands like list, op, ban, etc just work. Because it returns long string?

Also, when I issue command on a machine close to the game server (host - docker server distance), the command seems to always succeed. But on a remote machine (country - country distance) help usually fails.

[northkill]

I think this SO post explains it.

In some situation data transmission may be fragmented and recv should handle this case but mcrcon does not.

[Tiiffi]

@northkillz thank you!

This internet protocol and recv() fragmentation behaviour is definitely something I had overlooked and I will probably merge your pull request after some testing.

But there is something that bothers me. According to my tests /help command shouldn't even produce packets bigger than ~500 bytes.

Original issue description mentions expected packet size of 3133 which suggests that the server is trying to send more data than I would ever expect from /help command response.

First I was thinking it might be trying to send multi-packet responses (it's in Source RCON spec but wasn't supported by Minecraft at the time mcrcon was written) but maximun allowed single packet size is 4096 so it doesn't make sense to split the packet if the response size is only 3133 bytes.

For now I cannot reproduce the problem on my local network (with Vanilla 1.14.4 or Spigot 1.14.4) so it's still kinda mystery what exactly is going on (apart from the obvious internet protocol fragmentation).

I would be grateful if someone could provide pcap packet capture when this problem happens.
!!! Be careful not to include password in the capture !!!

[northkill]

When I issue help, server returns

/advancement (grant|revoke)
/ban <targets> [<reason>]
/ban-ip <target> [<reason>]
/banlist [ips|players]
/bossbar (add|get|list|remove|set)
/clear [<targets>]
/clone <begin> <end> <destination> [filtered|masked|replace]
/data (get|merge|modify|remove)
/datapack (disable|enable|list)
/debug (report|start|stop)
/defaultgamemode (adventure|creative|spectator|survival)
/deop <targets>
/difficulty [easy|hard|normal|peaceful]
/effect (clear|give)
/enchant <targets> <enchantment> [<level>]
/execute (align|anchored|as|at|facing|if|in|positioned|rotated|run|store|unless)
/experience (add|query|set)
/fill <from> <to> <block> [destroy|hollow|keep|outline|replace]
/forceload (add|query|remove)
/function <name>
/gamemode (adventure|creative|spectator|survival)
/gamerule (announceAdvancements|commandBlockOutput|disableElytraMovementCheck|disableRaids|doDaylightCycle|doEntityDrops|doFireTick|doLimitedCrafting|doMobLoot|doMobSpawning|doTileDrops|doWeatherCycle|keepInventory|logAdminCommands|maxCommandChainLength|maxEntityCramming|mobGriefing|naturalRegeneration|randomTickSpeed|reducedDebugInfo|sendCommandFeedback|showDeathMessages|spawnRadius|spectatorsGenerateChunks)
/give <targets> <item> [<count>]
/help [<command>]
/kick <targets> [<reason>]
/kill <targets>
/list [uuids]
/locate (Buried_Treasure|Desert_Pyramid|EndCity|Fortress|Igloo|Jungle_Pyramid|Mansion|Mineshaft|Monument|Ocean_Ruin|Pillager_Outpost|Shipwreck|Stronghold|Swamp_Hut|Village)
/loot (give|insert|replace|spawn)
/me <action>
/msg <targets> <message>
/op <targets>
/pardon <targets>
/pardon-ip <target>
/particle <name> [<pos>]
/playsound <sound> (ambient|block|hostile|master|music|neutral|player|record|voice|weather)
/recipe (give|take)
/reload
/replaceitem (block|entity)
/save-all [flush]
/save-off
/save-on
/say <message>
/schedule function <function> <time>
/scoreboard (objectives|players)
/seed
/setblock <pos> <block> [destroy|keep|replace]
/setidletimeout <minutes>
/setworldspawn [<pos>]
/spawnpoint [<targets>]
/spreadplayers <center> <spreadDistance> <maxRange> <respectTeams> <targets>
/stop
/stopsound <targets> [*|ambient|block|hostile|master|music|neutral|player|record|voice|weather]
/summon <entity> [<pos>]
/tag <targets> (add|list|remove)
/team (add|empty|join|leave|list|modify|remove)
/teammsg <message>
/teleport (<destination>|<location>|<targets>)
/tell -> msg
/tellraw <targets> <message>
/time (add|query|set)
/title <targets> (actionbar|clear|reset|subtitle|times|title)
/tm -> teammsg
/tp -> teleport
/trigger <objective> [add|set]
/w -> msg
/weather (clear|rain|thunder)
/whitelist (add|list|off|on|reload|remove)
/worldborder (add|center|damage|get|set|warning)
/xp -> experience

(I inserted new lines for readability)
I don't have any knowledge of RCON protocol, but if it's sent as ascii, that would be 2616 bytes (+ 10 bytes of header). I can't provide packet captures, because I'm using private tunnel to access the server, so packets are encrypted.

Anyway the only RCON protocol spec. I could find is Valve's Source RCON protocol, There's guarantee that data greater than maximum possible size (4096) will be split. But it does not mention the other case. So I think the behavior of sending data lesser than 4096 bytes is implement specific.

[Tiiffi]

Thank you.

That output listing was helpful. Looks like new server versions are pushing the help listing without pagination which explains the bigger packet sizes and makes the fragmentation problem more likely.

So basically they changed the behaviour a bit. Too bad they still didn't fix missing newlines in vanilla server.

Anyway, I merged your patch and it should be fine for now.