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

Kicking players for a too large payload can't be canceled #3509

Open
3 of 4 tasks
Timongcraft opened this issue Sep 1, 2023 · 7 comments
Open
3 of 4 tasks

Kicking players for a too large payload can't be canceled #3509

Timongcraft opened this issue Sep 1, 2023 · 7 comments

Comments

@Timongcraft
Copy link

Bungeecord version

git:BungeeCord-Bootstrap:1.20-R.02-SNAPSHOT:94ea027:1726 by md_5

Server version

git-Paper-169 (MC: 1.20.1) (Implementing API version 1.20.1-R0.1-SNAPSHOT) (Git: b4e3b3d)

Client version

1.20.1

Bungeecord plugins

none

The bug

If you send large packets you get a exception that "the payload is too large" and get kicked. Which in my opinion should just be managed by plugins and/or controlled by a config value.

Log output (links)

07:28:04 [WARNING] [Timongcraft] -> UpstreamBridge - could not decode packet! java.lang.IllegalArgumentException: Payload too large
07:28:04 [INFO] [Timongcraft] disconnected with: DecoderException : java.lang.IllegalArgumentException: Payload too large @ io.netty.handler.codec.MessageToMessageDecoder:98
07:28:04 [INFO] [Timongcraft] -> UpstreamBridge has disconnected

Checking

  • I am using BungeeCord and not a fork. Issues with forks should not be reported here.
  • I think this is not an issue with a bungeecord plugin.
  • I have not read these checkboxes and therefore I just ticked them all.
  • This is not a question or plugin creation help request.
@Janmm14
Copy link
Contributor

Janmm14 commented Sep 1, 2023

We are just enforcing vanilla protocol limits for the plugin message packet size.

Can you name any reasons on why you need this changed?

@Timongcraft
Copy link
Author

E.g. the Axiom Mod (https://axiom.moulberry.com) with the Plugin (https://github.com/Moulberry/AxiomPaperPlugin) is a very useful building mod which sends large custom packets.

@Outfluencer
Copy link
Collaborator

They should fix it in my opinion, its not a bungee issue

@Outfluencer
Copy link
Collaborator

If you could cancel the kick the packet would still not be read to the end and would get dropped

@Timongcraft
Copy link
Author

But why?
It works for example with velocity, so why should't it with bungeecord?

@Moulberry
Copy link

Moulberry commented Sep 1, 2023

I agree that it's not a bungeecord issue, but it's not so easy to fix on my end.

To clear up some confusion, the Paper plugin supports the increased packet size, so the 'vanilla limit' is being bypassed on Paper's side. It's just BungeeCord that won't let the packet through to Paper.

The mod & plugin supports changing the packet size limit here from 0x100000 to Short.MAX_VALUE, which would solve the disconnect on BungeeCord's side.

However, doing so will result in extreme performance degradation due to the large number of packets and reduced compressability of a 32k buffer compared to a 1mb buffer.

As the original poster said, a reasonable middle-ground would be to introduce a config option to change these limits. If this is an acceptable solution, I'd be happy to submit a pull request to this project.

Thanks, Moulberry

@Janmm14
Copy link
Contributor

Janmm14 commented Sep 2, 2023

I would prefer not making this a regular config option.

I suggest bungee doing one of these things:

  • Extract constant to static field so plugins can edit easier(still without guarantees on api)
  • Create hidden config option
  • Use system property

@md-5 md-5 changed the title [Bug]: Kicking players for a too large payload can't be canceled Kicking players for a too large payload can't be canceled Sep 2, 2023
Outfluencer added a commit to Outfluencer/BungeeCord that referenced this issue Dec 8, 2023
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

4 participants