node-minecraft-protocol
node-minecraft-protocol copied to clipboard
PrismarineJS
Client connection times out when packet over 2097152 bytes (2mb) is sent to client
In vanilla Minecraft, if a packet over roughly 2mb is sent to the client it will throw the following exception
When a large packet like this is sent to a minecraft-protocol client, the client times out and fails to decompress and/or parse the packet. This can be proven by modifying the /src/transforms/compressor.js file at line 69 to the following:
if(value < 2097152 - 90000){ this.push(newBuf) }
This will only parse the packet if its size is under 2mb. Upon implementing this patch, the client will successfully connect or remain connected to the server.
I can usually run minecraft-protocol easily on my system, but when an oversized packet is sent like this my computer begins slowing down and the fan begins to whir loudly, leading me to believe the process is allocating too much processing power to decompressing this packet. Below is the full error when the connection times out. The raw bytes logged in console right before the timeout is a map_chunk packet with too much NBT data.
I don't think the client should attempt to modify or repair these oversized packets, as that would cause client/server desync. If the client can parse it correctly, I see that as a successful fix.
Ok, do you have a way to reproduce this ? What server produce these big packets ?
On Tue, Dec 10, 2019, 18:27 PretendingToCode [email protected] wrote:
In vanilla Minecraft, if a packet over roughly 2mb is sent to the client it will throw the following exception
[image: image] https://user-images.githubusercontent.com/41800112/70551043-62ee6600-1b3c-11ea-943f-e5eee8ecbbb8.png
When a large packet like this is sent to a minecraft-protocol client, the client times out and fails to decompress and/or parse the packet. This can be proven by modifying the /src/transforms/compressor.js file at line 69 to the following:
if(value < 2097152 - 90000){ this.push(newBuf) }
This will only parse the packet if its size is under 2mb. Upon implementing this patch, the client will successfully connect or remain connected to the server.
I can usually run minecraft-protocol easily on my system, but when an oversized packet is sent like this my computer begins slowing down and the fan begins to whir loudly, leading me to believe the process is allocating too much processing power to decompressing this packet. Below is the full error when the connection times out. The raw bytes logged in console right before the timeout is a map_chunk packet with too much NBT data.
[image: image] https://user-images.githubusercontent.com/41800112/70552525-24a67600-1b3f-11ea-894b-1992fb8d66a0.png
I don't think the client should attempt to modify or repair these oversized packets, as that would cause client/server desync. If the client can parse it correctly, I see that as a successful fix.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/node-minecraft-protocol/issues/664?email_source=notifications&email_token=AAR437XQRCMGPDV6SXAH6B3QX7GPJA5CNFSM4JZCE56KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4H7Q2SQA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437RFTQMAQQUMVVNRNLDQX7GPJANCNFSM4JZCE56A .
A vanilla server can produce these packets. I created this packet by filling a 16x16x256 chunk with furnaces using WorldEdit. Since then, I've found it's easier to accomplish this via filling a chunk with roughly 1650 skinned player heads (can't be ones from creative menu, as they lack enough NBT data)
The two scenarios where this is most prevalent are with chunk packets, and inventory packets. Chunks when filled with blockEntities, and inventories when handling shulker boxes full of books with a lot of text in them.
Players know about this bug, and are actively exploiting it to prevent people from joining servers, effectively "banning" them since both of these packets are sent shortly after login.
Okay, could you share a world save with some chunk with this issue so I can reproduce ?
On Tue, Dec 10, 2019, 19:11 PretendingToCode [email protected] wrote:
A vanilla server can produce these packets. I created this packet by filling a 16x16x256 chunk with furnaces using WorldEdit. Since then, I've found it's easier to accomplish this via filling a chunk with roughly 1650 skinned player heads (can't be ones from creative menu, as they lack enough NBT data)
The two scenarios where this is most prevalent are with chunk packets, and inventory packets. Chunks when filled with blockEntities, and inventories when handling shulker boxes full of books with a lot of text in them.
Players know about this bug, and are actively exploiting it to prevent people from joining servers, effectively "banning" them since both of these packets are sent shortly after login.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/node-minecraft-protocol/issues/664?email_source=notifications&email_token=AAR437WTESLVJFCKJXFOWDTQX7LV5A5CNFSM4JZCE56KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQGV4Q#issuecomment-564161266, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437QHKQNKMGJKRBGBL5DQX7LV5ANCNFSM4JZCE56A .
Sure, here is the overworld file.
If you don't get an error upon connecting, chunk should be located around block coordinates (-250, 400) Loading the chunk should disconnect you.
Mojang just ignoring that bug in years. Maybe we should throw Exception then?
https://bugs.mojang.com/browse/REALMS-206
In reality, this doesn't appear to be a bug in vanilla Minecraft. Within the NettyCompressionDecoder class, there is an explicit check to see if the packet size is above a set threshold. https://github.com/ObelouixServer/Minecraft-1.12/blob/2f4d739d08c237147982e970dd9bbae927d07f49/src/minecraft/net/minecraft/network/NettyCompressionDecoder.java#L41-L44
Despite the issues this causes, it is Mojang's implementation. If the goal of this project is to mimic the vanilla client's netcode as closely as possible, there should be a check within /src/transforms/compressor.js to emit an error if a packet's size is over 2097152 bytes.