Timeout when connecting to Quilt + QSL server behind Velocity proxy

Question

Timeout when connecting to Quilt + QSL server behind Velocity proxy

unilock opened this issue 2 years ago · 35 comments

unilock commented 2 years ago

I'm trying to run a Quilt server behind Velocity.

When QSL is installed on the Quilt server, attempting to connect (through Velocity) results in the client hanging on the "Joining game..." screen for a few moments, followed by a "read timed out" error.

("the client" being a vanilla Minecraft client)

What does work:

Connecting to the Quilt server directly (bypassing Velocity)
Connecting through Velocity without QSL installed on the backend
Connecting through Velocity to an otherwise identical Fabric server (substituting QSL+QFAPI for the Fabric API)
- Fabric Loader: fabric-server-mc.1.19.2-loader.0.14.10-launcher.0.11.1.jar
- Fabric API: fabric-api-0.67.1+1.19.2.jar

The only thing that stands out to me in the logs is the following, printed to the client log when attempting to connect to the server:

[20:04:14] [Render thread/WARN]: Unknown custom packed identifier: qsl:registry_sync/handshake

Minecraft: 1.19.2
QSL: qfapi-4.0.0-beta.21_qsl-3.0.0-beta.21_fapi-0.67.0_mc-1.19.2.jar
Quilt Loader: 0.18.1-beta.16 (same with 0.17.6)
Velocity: 3.1.2-SNAPSHOT (git-2d072151-b185)

Client log: https://mclo.gs/2nCYdNG
Quilt server log: https://mclo.gs/EI40G0x
Velocity log: https://mclo.gs/dXmIbRM

unilock · Answer 1 · 2022-11-27T13:54:23.000Z

I thought d92a7d9 might have something to do with this issue, but qfapi-4.0.0-beta.1_qsl-3.0.0-beta.2_fapi-0.58.5_mc-1.19.1.jar (for 1.19.1), which includes said commit, also works fine!?

Frustrating!!!

unilock · Answer 2 · 2022-11-27T03:03:29.000Z

Update:
The same configuration under Minecraft 1.18.2 works fine!?
QSL: qfapi-1.0.0-beta.28_qsl-1.1.0-beta.26_fapi-0.67.0_mc-1.18.2.jar

roridev · Answer 3 · 2022-11-30T00:39:07.000Z

I had the same issue while running this on my server, a specific qfapi version "fixed" it, with the main problem being that it locks me on updating mods on my server.
qfapi-4.0.0-beta.7_qsl-3.0.0-beta.10_fapi-0.59.0_mc-1.19.2.jar (as seen at blocovermelho/server-mods@61b60b2)
I expect that a change in fabric api prior 0.59 broke compatibility with Velocity.

As I could personally "fix" the problem I delayed reporting this problem cause there was a patch for it and it seemed to be a very specific edge-case that no one else would need.

Fixing it by replacing it with fabric api isn't a possibility for me due to the server using switchy, which requires qsl.

Keeping it with this patch is also unwanted since that'd lock me into the current modpack, unable to update or add mods without fiddling with specific mod versions, likely also locking the server to 1.19.2, since anything with a hard dependency prior to fabric api 0.6 is incompatible.

Important notes from my experiments:

Quilt Server + Fabric API also works

unilock · Answer 4 · 2022-12-01T20:51:07.000Z

I can confirm that qfapi-4.0.0-beta.7_qsl-3.0.0-beta.10_fapi-0.59.0_mc-1.19.2.jar works, while the next (published) release, qfapi-4.0.0-beta.8_qsl-3.0.0-beta.13_fapi-0.59.0_mc-1.19.2.jar, does not.

Here's a diff between the two versions:
4.0.0-beta.7+0.59.0-1.19.2...4.0.0-beta.8+0.59.0-1.19.2

I suspect the issue has something to do with 1fa1608 and/or QuiltedRegistrySync.java... but what do I know?

LambdAurora · Answer 5 · 2022-12-01T20:54:35.000Z

In theory Quilt's registry synchronization was built to be compatible with proxies, but I guess we can't exclude the possibility that something went wrong.

unilock · Answer 6 · 2022-12-04T23:45:46.000Z

This is probably known, but qfapi-4.0.0-beta.23_qsl-3.0.0-beta.22_fapi-0.68.0_mc-1.19.2.jar, the (current) latest release of QSL, does not work :(

I would test 1.19.3, but Velocity doesn't support it quite yet, so no such luck...

EDIT: It should be mentioned that having QSL installed on the client-side as well makes no difference. (other than Unknown custom packed identifier: qsl:registry_sync/handshake not appearing)

EDIT: Not fixed with 1.19.3 / Quilt 0.18.1-beta.23 / QSL qfapi-5.0.0-alpha.3_qsl-4.0.0-beta.1_fapi-0.68.1_mc-1.19.3.jar. :(

unilock · Answer 7 · 2022-12-09T12:31:09.000Z

This action? https://github.com/QuiltMC/quilt-standard-libraries/actions/runs/3653399966

I feel like I may have done something wrong...
https://gist.github.com/unilock/02e845517fea20fa7a212272c3d28109
(This is with only qsl-4.0.0-beta.2+1.19.3-testmod.jar in the mods folder. I also tried with all the libs from the build added as well, but ran into the same error.)

EDIT: Note that I'm using Java 17. I see there's a workflow for building with Java 19 as well; maybe that's part of the issue?

unilock · Answer 8 · 2022-12-09T11:46:52.000Z

Hmm, this issue is probably better-suited for the quilt-standard-libraries issue tracker, but I don't know how to move issues 🤷‍♀️

LambdAurora · Answer 9 · 2022-12-09T12:00:22.000Z

This seems to point to registry sync but I think I'd like a confirmation that it is indeed caused by QSL alone and not QFAPI before moving the issue.

If someone can grab the test mod JAR of off QSL's GitHub Actions runs and test that would be appreciated!

LambdAurora · Answer 10 · 2022-12-10T11:42:14.000Z

I think your error is most likely a Quilt Loader issue, try updating it?

I also know that on Fabric to make Velocity work well an additional mod was required on the servers iirc

unilock · Answer 11 · 2022-12-10T13:48:59.000Z

That was on the latest version, unfortunately. Unless there's something newer than 0.18.1-beta.23?

Maybe you're thinking of FabricProxy-Lite? That (should) only be required when Velocity is set to "modern forwarding" mode, which I've disabled for the sake of testing.

unilock · Answer 12 · 2023-01-27T13:17:42.000Z

@Patbox That works!!
The below seems to be working fine:

Interacting with blocks / mobs
Generating chunks
Chat ("can't be verified", as expected)
Commands
Joining / Leaving (consistently)
...Getting kicked / banned (via /kick / /ban)

(I haven't tested with more than one player)

However, after having installed a few mods (that are required both client-side and server-side), the Quilt server prints the following error:

[08:07:04] [Netty Server IO #3/ERROR]: Received class net.minecraft.class_2828$class_2830 that couldn't be processed
java.lang.ClassCastException: class net.minecraft.class_3248 cannot be cast to class net.minecraft.class_2792 (net.minecraft.class_3248 and net.minecraft.class_2792 are in unnamed module of loader org.quiltmc.loader.impl.launch.knot.KnotClassLoader$Separate @3af6d7a7)
	at net.minecraft.class_2828$class_2830.method_11054(class_2828.java:16) ~[transformed-mod-minecraft.i0:0/:?]
	at net.minecraft.class_2535.method_10759(class_2535.java:167) ~[transformed-mod-minecraft.i0:0/:?]
	at net.minecraft.class_2535.method_10770(class_2535.java:152) ~[transformed-mod-minecraft.i0:0/:?]
	at net.minecraft.class_2535.channelRead0(class_2535.java:50) ~[transformed-mod-minecraft.i0:0/:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) ~[netty-handler-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.82.Final.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?]
	at java.lang.Thread.run(Thread.java:833) ~[?:?]

The mods common between the client and server:

The mods on the server only:

FabricProxy-Lite v2.4.0
Polymer v0.3.7
(your Quilt-Velocity patch mod)

roridev · Answer 13 · 2023-01-27T20:36:32.000Z

I'm unable to replicate @unilock's results using the Quilt-Velocity patch.

Quilt Loader `0.18.1-beta.60`

latest.log

ls ./mods/ -1
fabric-api-0.73.0+1.19.3.jar.disabled
FabricProxy-Lite-2.4.0.jar
polymer-bundled-0.3.7+1.19.3.jar
qfapi-5.0.0-beta.1_qsl-4.0.0-beta.9_fapi-0.73.0_mc-1.19.3.jar
quilt_velocity_patch-0.0.0+1.19.3.jar

Quilt Loader `0.17.10`

2023-01-27-6.log

ls ./mods/ -1
fabric-api-0.73.0+1.19.3.jar.disabled
FabricProxy-Lite-2.4.0.jar
polymer-bundled-0.3.7+1.19.3.jar
qfapi-5.0.0-beta.1_qsl-4.0.0-beta.9_fapi-0.73.0_mc-1.19.3.jar
quilt_velocity_patch-0.0.0+1.19.3.jar

Patbox · Answer 14 · 2023-01-27T20:44:15.000Z

Whats on client

roridev · Answer 15 · 2023-01-27T20:48:09.000Z

The client is using Adrenaline 1.12.0+1.19.3.quilt, which shouldn't impact testing.

I can confirm that a vanilla client has the same issues on both quilt loader versions.

roridev · Answer 16 · 2023-01-29T15:33:02.000Z

Was able to connect using the second patch on the minimal server case. Will test with my other mods to see if its fully fixed. (on quilt loader 0.17.10, haven't tested the beta)

Edit: The second test mod seems to have fixed the problem fully, on both the minimal case (for 0.17.10 and 0.18.1-beta.60) as well for my specific server use case (mostly server-sided mods with some support for optional client side mods). Haven't tested any content mods tho.

Patbox · Answer 17 · 2023-01-29T09:58:33.000Z

quilt_velocity_patch-0.0.0+1.19.3.zip
Test this one

unilock · Answer 18 · 2023-01-30T13:25:47.000Z

That patch seems to have fixed the (very few) content mods I was using 👌
(note that I've been using Quilt Loader 0.18.1-beta.59)
More testing should probably be done with more mods. I can get to that later.

unilock · Answer 19 · 2023-01-24T03:28:23.000Z

Unfortunately, the issue still exists in Minecraft 1.19.3, Quilt Loader 0.18.1-beta.58, and qfapi-5.0.0-alpha.9_qsl-4.0.0-beta.5_fapi-0.72.0_mc-1.19.3.jar :(

This time, however! I was able to get the QSL test mod up and running. (from this action)

I recorded two logs from a Minecraft 1.19.3 / Quilt Loader 0.18.1-beta.58 server with only that mod; one in which I connected to the Quilt server through Velocity, and the other in which I connected directly.

With Velocity
Without Velocity

So I guess it is a QSL issue after all?

roridev · Answer 20 · 2023-01-24T13:18:30.000Z

It is certainly a qsl issue.

I managed to "port" QForward to 1.19.3 in a very scuffed way, believing that was a problem with the way FabricProxy-Lite did modern forwarding, and since QForward explicitly targets quilt that wouldn't happen if the issue was on FabricProxy-Lite.

Neither QForward or FabricProxy-Lite work with QSL/QFAPI, but both of them work without QSL/QFAPI.

All of my tests were done in 0.17.10 and 0.18.1-beta.58 on minecraft 1.19.3.

This is a blocking problem from server networks that want to use quilt-loader. We can't use the "outdated qsl/qfapi version that doesn't timeout" trick in 1.19.3 (and all subsequent versions) cause mods are using newer versions of fapi/qfapi.

Of note is that QForward requires quilt_base, but I may be reading too much into this.

modImplementation(libs.quilt.qsl.core.base)

unilock · Answer 21 · 2023-01-25T11:46:59.000Z

I did some more testing connecting to the server with a Quilt client with the test mod installed.

Client log: Quilt client -> Quilt server with Velocity
Client log: Quilt client -> Quilt server without Velocity

Server log: Quilt server -> Quilt client with Velocity
Server log: Quilt server -> Quilt client without Velocity

(also I got the server logs from testing with a vanilla client yesterday)

Server log: Vanilla client -> Quilt server with Velocity
Server log: Vanilla client -> Quilt server without Velocity

Patbox · Answer 22 · 2023-01-26T18:01:55.000Z

This should fix it for now. At least I hope as I didn't test it. Just change .zip into .jar

quilt_velocity_patch-0.0.0+1.19.3.zip

unilock · Answer 23 · 2023-01-26T21:46:42.000Z

@Patbox With your mod installed, I'm able to connect to the Quilt server through Velocity! But I can't interact with anything (placing / breaking blocks, hitting mobs, etc.), and I'm constantly clipping into blocks, a la when a block is present on the server but not on the client - except the blocks are visible, and it happens with all blocks.
Chunks generate and mobs spawn and move around, at least.

Also, the Quilt server sometimes prints the following error when a player tries to join, followed by the player being kicked:

[16:43:48] [Netty Server IO #10/ERROR]: Received class net.minecraft.class_2828$class_2830 that couldn't be processed
java.lang.ClassCastException: class net.minecraft.class_3248 cannot be cast to class net.minecraft.class_2792 (net.minecraft.class_3248 and net.minecraft.class_2792 are in unnamed module of loader org.quiltmc.loader.impl.launch.knot.KnotClassLoader$Separate @1a5d0d94)
    at net.minecraft.class_2828$class_2830.method_11054(class_2828.java:16) ~[transformed-mod-minecraft.i0:0/:?]
    at net.minecraft.class_2535.method_10759(class_2535.java:167) ~[transformed-mod-minecraft.i0:0/:?]
    at net.minecraft.class_2535.method_10770(class_2535.java:152) ~[transformed-mod-minecraft.i0:0/:?]
    at net.minecraft.class_2535.channelRead0(class_2535.java:50) ~[transformed-mod-minecraft.i0:0/:?]
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:336) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:308) ~[netty-codec-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286) ~[netty-handler-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) ~[netty-transport-4.1.82.Final.jar:?]
    at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[netty-common-4.1.82.Final.jar:?]
    at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[netty-common-4.1.82.Final.jar:?]
    at java.lang.Thread.run(Thread.java:833) ~[?:?]
[16:43:48] [Server thread/INFO]: PLAYER[/127.0.0.1:52313] logged in with entity id 801 at (70.71692527738146, 70.06815128297653, -242.27902987058494)
[16:43:48] [Server thread/INFO]: PLAYER joined the game
[16:43:48] [Server thread/INFO]: PLAYER lost connection: Server sent an invalid packet
[16:43:48] [Server thread/INFO]: PLAYER left the game

...but sometimes I can join just fine, and no error is printed.

This is with Quilt Loader 0.18.0-beta.60, qfapi-5.0.0-alpha.9_qsl-4.0.0-beta.5_fapi-0.72.0_mc-1.19.3.jar, and FabricProxy-Lite-2.4.0.jar.

Patbox · Answer 24 · 2023-01-27T07:43:35.000Z

Try installing polymer too, might fix that

TheNukeLore · Answer 25 · 2023-03-21T02:47:51.000Z

what is the status on this issue? im using latest quilted fabric api alongside all the needed mods and velocity. on 1.19.4 and i still have such issues

unilock · Answer 26 · 2023-04-13T13:33:44.000Z

As an update: quilt_velocity_patch is still working fine with my "vanilla-compatible" Quilt server after updating to 1.19.4.
EDIT: Spoke too soon; players without Quilt installed themselves are kicked for having an "incompatible client" (as in, not modded). Then the server crashes with an exception related to Quilt's registry sync function??
EDIT2: The "incompatible client" error doesn't seem to be related to quilt_velocity_patch, but the fact that the server crashes after encountering said error probably is.

@james58899 Yes, this is an issue with Quilt / Velocity; it's unrelated to FabricProxy-Lite.

james58899 · Answer 27 · 2023-04-13T02:50:28.000Z

Someone reported the same issue in FabricProxy-Lite, but I believe this is caused by your mods, because the timeout occurs in the PLAY phase, not the LOGIN phase that FabricProxy-Lite affects.

If this cannot be fixed at the moment, I suggest mentioning in the mod's description that it does not work with Velocity.

unilock · Answer 28 · 2023-04-23T21:33:22.000Z

Since this issue has been confirmed(?) to be related to QSL's registry sync networking code specifically, might it make sense to move this to its issue tracker instead? (QuiltMC/quilt-standard-libraries)
(I am making the assumption that the issue does indeed have to do with QSL, because @Patbox's "quilt_velocity_patch" mixes into org.quiltmc.qsl.registry.impl.sync.ServerRegistrySyncNetworkHandler, and doesn't touch QFAPI at all.)

Patbox · Answer 29 · 2023-04-23T21:43:04.000Z

It is yes, but honestly it's more of an issue on velocity side of things

unilock · Answer 30 · 2023-04-23T22:33:02.000Z

Should an issue be opened on their tracker, then?
I assume this has already been discussed elsewhere, given the member names in quilt_velocity_patch (haha), but I can't find where that might've happened?

roridev · Answer 31 · 2023-05-01T14:20:38.000Z

This issue confuses us a lot, since it is at the same times:

"An issue on the side of velocity"

"Unrelated to fabricproxy-lite"

"Fixed by a patch applied to Quilt's implementation of ServerRegistrySyncNetwork"

"Can be replicated with just QFAPI/QSL"

"Older versions without the Registry Sync rewrite don't exhibit that behaviour"

Where should we report this bug.

Is it here since a change to this project caused the interaction to misbehave, or on Velocity, since its a problem on their side, even thought admittedly this was already been discussed and went nowhere.

james58899 · Answer 32 · 2023-05-05T01:27:25.000Z

Quilt sent a PLAY state packet before Velocity switched from LOGIN state to PLAY, so Velocity discarded the packet, and Quilt waited for the response timeout¹.

I think this issue can be fixed by both sides, but I don't see related issue reports in Velocity. If the Quilt developer thinks it should be fixed by Velocity, please open an issue at Velocity, otherwise Quilt should fix it itself.

https://discord.com/channels/289587909051416579/908507866183372801/1065111650803404871 ↩

unilock · Answer 33 · 2023-05-16T13:21:32.000Z

I managed to work around the issue on 1.19.2 by backporting Polymer's "sendGameJoinBeforeSync" functionality from >=1.19.3, then using that in conjunction with quilt_velocity_patch (which works as-is on 1.19.2).

My fork of Polymer including said backport: https://github.com/unilock/polymer/tree/dev/1.19.1-proxyfix

The combination of Polymer + quilt_velocity_patch works on 1.19.4 as well, if that wasn't clear. (Provided sendGameJoinBeforeSync is enabled - which it should be by default if another proxy compatibility mod is detected (FabricProxy-Lite, etc.))

Patbox · Answer 34 · 2023-05-16T13:50:29.000Z

Btw, feel free to pr that backport, just maybe move mod checks from registry sync manipulator to polymer/impl/compat one instead

Player505 · Answer 35 · 2024-02-07T14:36:44.000Z

Minecraft 1.20.1 quilt server still has the issue Unknown custom packed identifier: qsl:registry_sync/handshake when behind a proxy which can still be fixed by installing polymer

Share to

Important notes from my experiments:

Quilt Loader 0.18.1-beta.60

Quilt Loader 0.17.10

Footnotes

Quilt Loader `0.18.1-beta.60`

Quilt Loader `0.17.10`