io.netty.buffer.PooledDirectByteBuf cannot be cast to class net.md_5.bungee.protocol.PacketWrapper

[XIII-MC]

Describe the bug
The LOGIN_START packet cannot be cancelled then sent back later using User.receivePacketSilently.

To Reproduce
Steps to reproduce the behavior:

1. Use BungeeCord (using BungeeCord-Bootstrap:26.1-R0.1-SNAPSHOT:edb28b4:2083 here)
2. Join with any client
3. See error

Expected behavior
It should work seemlessly like how it does on Spigot:
The packet gets cancelled, the API does the fetch async then triggers the receivePacketSilently to continue the login flow.

Platform information (please complete the following information):

• OS: Fedora KDE 44 (7.1.3-200.fc44.x86_64)
• Platform: BungeeCord
• CoralGate version: 0.3.2-SNAPSHOT (0.4.3-SNAPSHOT)
• packetevents version: 2.13.0

Additional context
This issue has been known since February but hasn't been fixed yet, despise Bungee and PE updates (retrooper/packetevents#1465).
This actively prevents the release of BungeeCord support.

Stack trace:

21:03:40 [SEVERE] [/127.0.0.1:51402] <-> InitialHandler - encountered exception
java.lang.ClassCastException: class io.netty.buffer.PooledDirectByteBuf cannot be cast to class net.md_5.bungee.protocol.PacketWrapper (io.netty.buffer.PooledDirectByteBuf and net.md_5.bungee.protocol.PacketWrapper are in unnamed module of loader 'app')
        at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:117)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.github.retrooper.packetevents.impl.netty.channel.ChannelOperatorImpl.fireChannelReadInContext(ChannelOperatorImpl.java:85)
        at com.github.retrooper.packetevents.netty.channel.ChannelHelper.fireChannelReadInContext(ChannelHelper.java:73)
        at io.github.retrooper.packetevents.impl.netty.manager.protocol.ProtocolManagerAbstract.receivePacketSilently(ProtocolManagerAbstract.java:81)
        at com.github.retrooper.packetevents.manager.protocol.ProtocolManager.receivePacketsSilently(ProtocolManager.java:94)
        at com.github.retrooper.packetevents.manager.protocol.ProtocolManager.receivePacketSilently(ProtocolManager.java:148)
        at com.github.retrooper.packetevents.protocol.player.User.receivePacketSilently(User.java:235)
        at cloud.gteam.coralgate.processor.NetworkProcessor.lambda$onPacketReceive$0(NetworkProcessor.java:337)
        at java.base/java.util.concurrent.CompletableFuture.uniAcceptNow(CompletableFuture.java:778)
        at java.base/java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:756)
        at java.base/java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:2241)
        at cloud.gteam.coralgate.processor.NetworkProcessor.onPacketReceive(NetworkProcessor.java:327)
        at com.github.retrooper.packetevents.event.PacketListener$1.onPacketReceive(PacketListener.java:41)
        at com.github.retrooper.packetevents.event.PacketReceiveEvent.call(PacketReceiveEvent.java:52)
        at com.github.retrooper.packetevents.event.EventManager.callEvent(EventManager.java:85)
        at io.github.retrooper.packetevents.handlers.PacketEventsDecoder.read(PacketEventsDecoder.java:59)
        at io.github.retrooper.packetevents.handlers.PacketEventsDecoder.decode(PacketEventsDecoder.java:83)
        at io.github.retrooper.packetevents.handlers.PacketEventsDecoder.decode(PacketEventsDecoder.java:37)
        at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:91)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:361)
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:325)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.handler.codec.ByteToMessageDecoder.handlerRemoved(ByteToMessageDecoder.java:270)
        at io.netty.handler.codec.ByteToMessageDecoder.decodeRemovalReentryProtection(ByteToMessageDecoder.java:553)
        at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:484)
        at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:296)
        at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
        at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1429)
        at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:918)
        at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:804)
        at io.netty.channel.epoll.AbstractEpollChannel$AbstractEpollUnsafe.handle(AbstractEpollChannel.java:487)
        at io.netty.channel.epoll.EpollIoHandler$DefaultEpollIoRegistration.handle(EpollIoHandler.java:349)
        at io.netty.channel.epoll.EpollIoHandler.processReady(EpollIoHandler.java:546)
        at io.netty.channel.epoll.EpollIoHandler.run(EpollIoHandler.java:491)
        at io.netty.channel.SingleThreadIoEventLoop.runIo(SingleThreadIoEventLoop.java:225)
        at io.netty.channel.SingleThreadIoEventLoop.run(SingleThreadIoEventLoop.java:196)
        at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:1195)
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
        at java.base/java.lang.Thread.run(Thread.java:1474)

Problematic line:

packetUser.receivePacketSilently(new WrapperLoginClientLoginStart(wrapperLoginClientLoginStart.getClientVersion(), username, wrapperLoginClientLoginStart.getSignatureData().orElse(null), wrapperLoginClientLoginStart.getPlayerUUID().orElse(null)));

Potential resolution
Either the API request is done sync (which WILL block Netty threads and could drop connections)
OR
The API check is disabled or kept async, this is a way less effective protection
OR
Try manually triggering onPacketReceive locally ? Not sure the client will understand whats happening tho...

[XIII-MC]

A "fix" is in place but it's TERRIBLE.
It doesn't control the packet flow, meaning the time the API takes to decide if the IP is malicious or not leaves enough headroom for bots to fully establish a connection and retrieve some information about the server.

Will try to make it onPacketSend side. Maybe controlling server sent packets will have better results? We'll see...

[XIII-MC]

A cleaner working fix (that actually holds the packet WITHOUT blocking the threads) has been deployed.

I forgot the mention the issue, here's the commit hash: bd1aaec

Exclusive to proxies and works perfectly on BungeeCord and Velocity. This does allow for ENCRYPTION_REQUEST AND SET_COMPRESSION to leak...

This will be removed once PE fixes the issue.