Compatibility with FFAPI and Velocity

[Sam-Chai]

Affected Product(s)

SpongeNeo

Version

spongeneo-1.21.1-21.1.35-12.0.2-universal

Operating System

Windows for server, macOS for client

Java Version

java 21

Plugins/Mods

- Forgified Fabric API(FFAPI)
- Sponge
- Velocity (Proxy)
- *NeoVelocity*

Describe the bug

Here is the bug:
If I installed the FFAPI and Sponge, then cannot setup the proxy setup. The client shows "Unexpected custom data from client" (In some cases shows "Timed out")

In other issues (from connector, the FFAPI and the NeoVelocity) they telled me it seems like the FFAPI send a custom packets but the Neo (ofcourse in my case is Sponge) cannot understand these packets, and fire the vanilla handleCustomQueryPacket method on ServerLoginPacketListenerImpl class. Then kicked out.

Here is the issue links:

• Couldn't connect from proxy if fabric_networking_api_v1 is installed Gabwasnt/NeoVelocity#10
• Incompatible with modern forwarding Sinytra/ForgifiedFabricAPI#185
• Networking API prevents clients from connecting when running behind Velocity Sinytra/ForgifiedFabricAPI#233

I found that the NeoVelocity already fixed this bug:
Gabwasnt/NeoVelocity#13

Of course I can't install NeoVelocity on the Sponge because the Sponge handled the networking for the proxy.

The Sponge code:https://github.com/SpongePowered/Sponge/blob/b3a10010172ad764178134c4146b89026c5632ab/src/mixins/java/org/spongepowered/common/mixin/core/server/network/ServerLoginPacketListenerImplMixin.java#L290C23-L290C46

@Inject(method = "handleCustomQueryPacket", at = @At("HEAD"), cancellable = true)
    private void impl$onHandleCustomQueryPacket(final ServerboundCustomQueryAnswerPacket packet, final CallbackInfo ci) {
        final CustomQueryAnswerPayload payload = packet.payload();
        final int transactionId = packet.transactionId();
        if (!(payload instanceof SpongeChannelPayload
            // some clients may answer a null payload to unknown queries
            || (payload == null && ((ConnectionBridge) this.connection).bridge$getTransactionStore().contains(transactionId)))) {
            return;
        }

        ci.cancel();

        this.server.execute(() -> {
            final SpongeChannelManager channelRegistry = (SpongeChannelManager) Sponge.channelManager();
            final EngineConnection connection = ((ConnectionBridge) this.connection).bridge$getEngineConnection();
            channelRegistry.handleLoginResponsePayload(connection, (EngineConnectionState) this, transactionId, payload == null ? null : ((SpongeChannelPayload) payload).consumer());
        });
    }

Is there any possible to fix that out? I think to add the NeoVelocity's fix is enough.

Thanks!!!

Link to logs

No response

[aromaa]

Sponge already has built in support for proxies. https://docs.spongepowered.org/stable/en/server/getting-started/bungeecord.html

If this repros with it, we can take a better look.

[Sam-Chai]

Sponge already has built in support for proxies. https://docs.spongepowered.org/stable/en/server/getting-started/bungeecord.html

If this repros with it, we can take a better look.

Yeah, when the Sponge enable the ip-forward and mode is MODERN, the player connect the server via the Velocity, and the server installed the FFAPI, then returns me "Unexpected custom data from client". This is the known bug on the FFAPI, the NeoVelocity is already fix this problem, I hope the sponge can fix it either.

[aromaa]

I made some changes in b61dee3 to better account for other mods but unfortunately theres no way to make FFAPI work reasonably without changes inside the mod.

The mod records every packet sent in the connection here regardless of the sender and waits for a response. For receiving, the mod expects to see every packet it observed to be outgoing and mark it as handled. This would work just fine IF the mod just didn't discard all the content here that there is after it failed to handle the requests.

This now means that if Sponge handles the request first, FFAPI doesn't see the packet and the mod will be indefinitely waiting for the response. If Sponge handles the request after, we no longer have access to the content.

Alternatively, we could have a WrapMethod + Inject + @Share combo but I do not think the complexity is justified here given that this is easily fixable on the mod side.

[p0t4t0sandwich]

Proxy Compatible Forge's solution (simplified from NeoVelocity) was to do a reflection operation to remove just the query ID from FFAPI's handler list.
https://github.com/p0t4t0sandwich/Proxy-Compatible-Forge/blob/update/v1.1.8/neoforge/neoforge-1.20.2/src/main/java/org/adde0109/pcf/v1_20_2/neoforge/Compatibility.java#L38

Doing it this way prevents FFAPI from handling the packet in the first place, so there's no issue with the data being discarded, preventing the login stall-out.

[p0t4t0sandwich]

Actually, now that I look at it, I'm not entirely sure why removing it just the once works
Yep, after further testing it needs to be done each time, no clue how it was working previously