-
Notifications
You must be signed in to change notification settings - Fork 50
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
Incompatiability with ViaVersion #50
Comments
Hi, Thanks for your report. We have tried with the steps indicated but have been unable to reproduce. Did you have ProtocolLib installed in your case? If so, could you also let me know the Java version used? Thanks |
Yes. ProtocolLib was installed, and Java is on Java 11. Also note I am using TCPShield 2.4. 2.5 doesn't work with the reverse proxy I'm using yet. If you can reproduce this bug on 2.4 but not 2.5 I will close this issue. |
Oops, accidentally closed the issue. Reopened :) |
Can you elaborate more on the incompatibility issues you described with your reverse proxy (on 2.5)? |
I'm using Infrared reverse proxy. 2.5 broke Infrared since Infrared sends the payload that was correct in 2.4 but is no longer accepted in 2.5 because of the new payload validation; I'm waiting for it to update. |
Hi, I am another contributor to this. I am not sure what you mean by this, the payload data was the same throughout 2.4 and 2.5, it's just 2.4 ignored some of the validation sections in the payload. Are you able to send debug information showing what payload data is received, or if it's another error entirely. If we get 2.5 working for you, then your original issue should be fixed. Thanks |
This is the issue as marked by Infrared. It points out specific lines of code & errors that I helped to debug (I worked with the original poster in diagnosing the error). |
Thanks for the insight, I'm still a little confused on how Infrared causes the signature to be removed completely, and preserve every other section (at least it isn't outlined in the issue). As I see, this issue would have occurred on versions 2.3 and lower as well; this isn't a "new" bug from this specific version. I'll be happy to work on this issue once I get more information on the Infrared side of things. |
Infrared sent the payload without the signature, which worked in 2.4. It seems that in 2.5 it's looking for 4 payload arguments (the original 3 + the signature) and when Infrared only sends the original 3 arguments (without the signature) RealIP ignores the request since there is no validation signature. |
Yeah, but I'm referring to why Infrared removes the signature argument at the end, this could be fixed with slight tweaking on TCPShield's end if its something simple. |
I don't believe the signature argument was present (or required/enforced) in 2.4. |
It was present, just ignored along with the timestamp verification. The current verification system was used in older versions (discluding the IP whitelisting with CIDR). 2.4 looked for only 2 sections which allowed this issue to fly under the radar. But I still don't know why Infrared removes the end of the payload. |
Infrared doesn't remove the signature. The feature @gcurtiss is talking about upgrades the handshake packet to mimic what TCPShield would send. This enables the preservation of IP addresses like HAProxy protocol does without needing BungeeCord or other HAProxy solutions. |
That makes way more sense now, thanks for clearing that up 👍🏻. So I guess the solution is to turn that option off since IP manipulation is already handled by TCPShield. |
There is a slight problem here, TCPShield the service isnt being used. This is the only way it makes sense what is happening would be if @gcurtiss refer to
Its possible to have a client connection: If you try to connected with a server which has RealIP 2.5 and you try to join with |
I run a 1.16 server. I use ViaVersion so that people connecting from older versions can connect to the server just fine.
However, the people connecting to my server using older versions of Minecraft (1.12 being the most common) don't get their real IP revealed, it just shows the IP of my proxy server.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: