Bug Report: Disconnect packet sometimes causes a client error

[jonesdevelopment]

General information

Time: 2024-06-25 17:10:08
Description: Packet handling error

java.net.SocketException: Connection reset
	at java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:401)
	at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:434)
	at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:254)
	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:357)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562)
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
	at java.base/java.lang.Thread.run(Thread.java:1583)

Steps to reproduce

1. Pass the verification
2. Hope for the very small chance that you won't receive the actual disconnect message, but rather be kicked for some kind of error

Sonar dump

/

Additional information

No response

[jonesdevelopment]

I am unable to replicate this bug. I've unblocked this issue and will leave it open for a little while longer.

[aggre666ion]

Is this happening to me every time i tried to join to my server my only solution has been reducing chunks render however connection is terrible eventhough normally my network is stable in other apps

[jonesdevelopment]

Is this happening to me every time i tried to join to my server my only solution has been reducing chunks render however connection is terrible eventhough normally my network is stable in other apps

I find it hard to believe that the render distance or networking has anything to do with how the client handles a disconnect packet. Could you provide more information (e.g. client logs, or a screenshot)?

[Chumb3x]

I have never encountered this issue

[NoGodHenry]

Is this happening to me every time i tried to join to my server my only solution has been reducing chunks render however connection is terrible eventhough normally my network is stable in other apps

What operating system are you using and what operating system is the server using?

[jonesdevelopment]

This could potentially be caused by TCPShield or another reverse proxy/DDoS protection service. I've personally never encountered this, and no one I've spoken with has either.

[xism4]

This could potentially be caused by TCPShield or another reverse proxy/DDoS protection service. I've personally never encountered this, and no one I've spoken with has either.

I don't think so, since the only time it could affect would be before entering and that is when the requests are searched.

I understand that sonar does not check packets in-game only at login, right?

[jonesdevelopment]

I don't think so, since the only time it could affect would be before entering and that is when the requests are searched.

I understand that sonar does not check packets in-game only at login, right?

I'm using the disconnect packet from Velocity, so I don't think the packet itself is causing any issues.

The packet can be sent during login and during the game state. Depending on the state, a different component is used (NBT or stringified; depending on the version). I also took this from Velocity, and I haven't found any issues during my tests.

[xism4]

he packet can be sent during login and during the game state. Depending on the state, a different component is used (NBT or stringified; depending on the version). I also took this from Velocity, and I haven't found any issues during my tests.

Then I think it is discarded, since it uses limits provided by the protocol itself that match the client.

[NoGodHenry]

he packet can be sent during login and during the game state. Depending on the state, a different component is used (NBT or stringified; depending on the version). I also took this from Velocity, and I haven't found any issues during my tests.

Then I think it is discarded, since it uses limits provided by the protocol itself that match the client.Then I think it is discarded, since it uses limits provided by the protocol itself that match the client.

I don't think the window size would play any role in it. Even if TCP window scaling wasn't used, there's no way the window size is smaller than the disconnect packet size + 54 bytes.

[jonesdevelopment]

I got this once. The server is proxied through TCPShield. I haven't been able to reproduce it without TCPShield.

[13:52:09] [Render thread/WARN]: Client disconnected with reason: Disconnected

[jonesdevelopment]

I'm like 90% sure this is caused by TCPShield or any sort of reverse proxy. Btw, TCPShield also messes up disconnect packets when you connect to a server using an invalid hostname (you can also just join on one of their direct IPs):

[HAMMERxPL]

They scam so what do you expect? Neoprotect will also likely get banned for scamming.

[jonesdevelopment]

I was unable to reproduce this without TCPShield or other third-party services sending malformed packets or terminating the channel. Even so, it happens very rarely.