Packet/NBT Tag Size issue caused by Velocity

[LandonDeam]

Steps to reproduce packet size issue:
Run a 1.19.2 Fabric server with the Dogcraft modpack under a Velocity server. Attempt to connect. Be met with the following (server side): https://mclo.gs/IHaC5YP

Steps to reproduce NBT tag size issue:
Run a 1.19.2 Fabric server with the mods Chipped, Consistency+, Continuity, Create, and Create Deco (all of which are in the aforementioned modpack) under a Velocity server. Attempt to connect. Be met with the following (client-side): https://mclo.gs/IUUz5pu

My best guess as to the cause: Velocity probably shares/uses the same built-in, hard-coded values for packet sizes and NBT tags as vanilla, and as soon as it sees something go over these limits, it throws up an error and disconnects the player, even if the player would have not been kicked by the Minecraft server itself.
Note: This is also pure speculation, so feel free to look for other explanations if this is not the case.

Additional Info: These errors do not occur when running the server bare, without Velocity. The root cause would seem to be Velocity somehow mishandling data that is too large, which tends to happen with the listed mods for some reason (which is strange, considering they basically all just add blocks). I also would use the Connectivity mod and call it a day, but it seems to have some sort of conflict with at least one of the other mods in the above pack (the reason I am reporting this in the first place), so that solution is out the window for the time being.

[LandonDeam]

I'm currently suspecting it's something that occurs between lines 68 and 81 in the MinecraftDecoder class, as this would be the time for Velocity to so sanity checks on the buffer (and throw errors similar to the one described), and this function is only called by another function that, seemingly, would not have any effect on the packet/buffer. That is, of course, unless ByteBuf has a maximum buffer size set somewhere, and I'm just unfamiliar with the class.

[newtykip]

I am also having issues with NBT tag sizes. I am running Prominence II. However, my issues are on the server side. This is what my error looks like: https://mclo.gs/E8OtNbU

[Schmazda]

It actually looks like Velocity does not support the Fabric-API properly. Fundamental additions made to the Login Process are not supported by Velocity and are causing these errors. Essentially Velocity has to extend their Login to support said additions made by fabric. Otherwise some crucial packets are either corrupted or not forwarded at all

[newtykip]

My issue revolved around a mod implementing a custom handshake protocol which Velocity did not understand. After I added the compat plugin, this error amongst others disappeared. I do not know if Dogcraft has any mods which also implement custom protocols, but it might be worth investigating.

[Schmazda]

Yeah, it could be possible to generalize this approach so that every channel gets forwarded like that, but I'm not sure. Either way this would be a temporary workaround and by no means a fix that should be used in production.

[Schmazda]

LandonDeam's Problem is probably that (Login-)PluginMessages with the Channel-ID fabric-networking-api-v1:early_registration are not forwarded properly which causes kind of a chain reaction that results in non-joinable Fabric servers when the Fabric Registry's size reaches a certain threshold. This should at least apply to the Packet-Size problem.

[electronicboy]

owo handshaking occured during the LOGIN phase, a connection phase in which we cannot force the client back into; their compat plugin basically just makes the proxy cache the handshake that occurs during that phase in order to allow it to "support" the thing. blindly resending stuff during that phase is not a solution in which is anything but a hack likely to induce more problems than it solves, thankfully, 1.20.2 has a better solution for that issue.

The entire login phase is generally borked, because we assume that we don't need to have a client and a server talking to one another, given that it's literally impossible to even allow that to happen past the first server, it's never been a big consideration until attempting to design a means to reset modded clients into reconnecting came into play