Cannot connect to singleplayer or multiplayer as of v2.3.1 - "Unexpected custom data from client"

[unilock]

As of version 2.3.1 of Porting Lib, I'm unable to connect to a dedicated server - the client is almost instantly disconnected with the error "Unexpected custom data from client".

latest.log from client: https://gist.github.com/unilock/794de8311574ee811db993e8d08123e7
latest.log from server: https://gist.github.com/unilock/6ed314c2739792ccaf850755ad098ede

Note that I'm using Quilt (Loader 0.24.0, QFAPI 7.5.0 / QSL 6.1.2), with the server behind a Velocity proxy.

The issue exists on Porting Lib v2.3.2 as well. Downgrading Porting Lib to v2.3.0 resolves the issue.

[TropheusJ]

Porting Lib syncs configs on login. Velocity seems unable to handle that.

[TropheusJ]

A vanilla server will disconnect any client that sends a custom login query, which is what's happening here. FAPI adds support for them.

[unilock]

Great, another issue with Velocity not allowing custom packets during the LOGIN stage. There have been multiple discussions with the Velocity team about this, but they refuse to account for anything other than vanilla behavior.

When Quilt had the same issue (https://github.com/QuiltMC/quilted-fabric-api/issues/46), a server-side mod was created that sent ClientboundLoginPacket / GameJoinS2CPacket earlier in the handshake to make Velocity think that the client was already in the PLAY stage, thus allowing custom packets to go through.

Since Velocity unfortunately does not care, could something similar be done here?

[TropheusJ]

It might be possible to move sync to PLAY. Changing when vanilla packets are sent sounds extremely dangerous.

[TropheusJ]

Seems to not actually be a velocity problem

[TropheusJ]

It seems to be a problem with config sync, but it's normally hidden because nothing happens if no mods use it. Hephaestus uses it.

[unilock]

Changing when vanilla packets are sent sounds extremely dangerous.

If I remember correctly, the order of packets wasn't changed; rather, GameJoinS2CPacket was sent twice: once earlier in the handshake to trick Velocity into allowing custom packets, and again when it would have normally been sent by vanilla logic.

But that's probably neither here nor there. Glad to hear this isn't a Velocity issue at least :)

[unilock]

I've just noticed that this also happens when trying to join a singleplayer world.

debug.log: https://gist.github.com/unilock/4270472621816cf921b0f67a162be697

The timestamp in which I started a singleplayer world would be [08:50:00], I believe. (line 23972)

[solonovamax]

I believe that I'm experiencing the issue with fabric 0.15.9, mc version 1.20.1, using create 0.5.1-f-build.1417+mc1.20.1, which bundles porting lib 2.3.2. I can provide logs if needed.

[AlienXtream]

same here. dont seem to be able to downgrade either. took me 3 days to narrow down the problem to porting lib. i see there is a pull request that allegedly fixes this. hope we get that patch soon

[solonovamax]

same here. dont seem to be able to downgrade either. took me 3 days to narrow down the problem to porting lib. i see there is a pull request that allegedly fixes this. hope we get that patch soon

you can build porting lib from source with the correct patch (7ba0f31a65a9a25c2fbf3ce1798e55b28d41c5c8) applied, and include the resulting binary in your mods folder.

[AlienXtream]

i have no clue how to do that alas

[Azure-Agst]

Lucky for us, Porting Lib has a Github Actions workflow that builds a JAR after every push/PR against the repo. You can find the corresponding artifact for #101 here.

Download the Artifacts.zip and extract it. Your updated JAR should be in there. Adding this version to my mods folder fixed the issue and allowed me to load Create 1.20.1 v0.5.1.f Patch 1 without the "Unexpected custom data" error.

This should work until the patch is merged upstream and released via an update.

[TropheusJ]

fixed