Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TCPShield alters timestamps? and protocol version of packets #34

Closed
Sabinno opened this issue Jan 30, 2021 · 2 comments
Closed

TCPShield alters timestamps? and protocol version of packets #34

Sabinno opened this issue Jan 30, 2021 · 2 comments

Comments

@Sabinno
Copy link

Sabinno commented Jan 30, 2021

I use a game management panel called AMP by CubeCoders; it is quite popular and is updated regularly.

I tried to use AMP's "sleep" feature (which effectively shuts down the server until a player pings the server, then immediately starts it on the fly) with a server and noticed that I was getting this error:

[23:50:38] [Minecraft:esabin Warning] : Sleep packet timestamp doesn't match! (Expected 1611964238278, got 0)
[23:50:38] [Minecraft:esabin Warning] : Unable to get protocol version. Sleep mode will be unavailable.

I started a brand new instance, installed Paper 1.16.5 (latest as of writing), then started the server with sleep mode enabled. Works perfectly. I then installed ProtocolLib (latest as of writing); still works great. Lastly, I installed TCPShield 2.4 (latest as of writing); sleep mode is now broken and produced the error shown above.

Absolutely no configuration was changed from default on the test servers.

I have concluded that TCPShield messes with timestamps of packets or their protocol version in such a non-standard way that they cause problems with other applications. Is there a way to fix this?

@JosiahWhite
Copy link
Collaborator

This is likely due to our plugin blocking connections from hosts that did not connect through the TCPShield network and the plugin is trying to find the protocol version by connecting directly. The solution for this would be to identify the source IP address by enabling debug mode on the TCPShield plugin so that it shows blocked connections, and adding the according IP to a new file under the ip-whitelist directory created by this plugin.

@Sabinno
Copy link
Author

Sabinno commented Feb 1, 2021

Whitelisting 127.0.0.1 fixed the issue, as that is where the request originates. Thanks for the heads up!

@Sabinno Sabinno closed this as completed Feb 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants