cloudburstmc / network Goto Github PK

View Code? Open in Web Editor NEW

45.0 45.0 42.0 972 KB

Network components

License: Apache License 2.0

Java 100.00%

network's People

Contributors

Stargazers

Watchers

network's Issues

[v2] Disconnect packet is never/not properly sent

When disconnecting from a server, the server does not get notified of the disconnect

Unable to connect to some servers (probably those that use the pocketmine core)

The client does not receive a response to the open connection request packet from server, probably the server does not expect it. However, according to the raknet documentation (https://wiki.vg/Raknet_Protocol), the implementation does everything correctly, and any raknet server must accept a sequence of handshakes/open connection requests in the described way. However, some servers (in particular those using Pocketmine as their core) do not respond to the first connection open request packet and all subsequent.
Also I noticed that the Minecraft client decides based on pong data whether to send handshakes to the server or not (in addition, https://github.com/PrismarineJS/bedrock-protocol always pings the server before connecting and changes the behavior depending on the response), although I did not quite understand what exactly should be in pong to change the behavior of an open connection.
Maybe Raknet supports the outdated way of opening connections, and if the pong came in an outdated format, the client uses an outdated way to open the connection? I also tried changing the rak_protocol_version and rak_mtu options, but it didn't help. Moreover, ping works great.
In general, this implementation and projects using it cannot open a connection with the some raknet servers (e.g. casescraft.ru:19133) at the handshake level. I would like to know if I have not understood something or if this is a bug?

Abusing NACK caused large number of packet wrong retransmissions

The Raknet protocol was not processed correctly, so that although the Geyser server received many packets correctly, it still sent a NACK to tell the client that it did not receive it, causing the client to retransmit for no reason, wasting a lot of bandwidth.

Connecting times out

When trying to connect to lootmc.com the connection times out. Connecting using a bedrock client works fine.
Minimal reproduceable example

    public static void main(String[] args) throws Throwable {
        System.out.println("connecting");
        new Bootstrap()
                .channelFactory(RakChannelFactory.client(NioDatagramChannel.class))
                .group(new NioEventLoopGroup())
                .option(RakChannelOption.RAK_PROTOCOL_VERSION, 11)
                .option(RakChannelOption.RAK_CONNECT_TIMEOUT, 4_000L)
                .option(RakChannelOption.RAK_SESSION_TIMEOUT, 30_000L)
                .option(RakChannelOption.RAK_GUID, ThreadLocalRandom.current().nextLong())
                .handler(new BedrockClientInitializer() {
                    @Override
                    protected void initSession(BedrockClientSession session) {
                        System.out.println("connected");
                        session.setCodec(Bedrock_v594.CODEC);
                        session.setPacketHandler(new BedrockPacketHandler() {
                        });
                    }
                })
                .connect(new InetSocketAddress("lootmc.com", 19132))
                .syncUninterruptibly();
    }

In this example "connected" is never printed

Send pack blocking problem

My server is a bedrock server with geyser.

Hardware:
total 23 servers.per server is 128G 22core 44 thread , and total 1G bandwidth. max online players about 14K.

video:
this is the player's video.
https://youtu.be/xHCFvL0DtNA
for other player, this player like forzen.

When this probelm happen,

The player will get a high network flow.
and I have dump the memory twice.
The second memory is after 30s by the first.

first

second

RakNet Security layer is not supported

When trying to connect to play.timecrack.net the following error is thrown. A vanilla Bedrock client can join the server without issues.

java.lang.SecurityException: null
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOfflineHandler.onOpenConnectionReply1(RakClientOfflineHandler.java:158) [ViaProxy.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOfflineHandler.channelRead0(RakClientOfflineHandler.java:128) [ViaProxy.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOfflineHandler.channelRead0(RakClientOfflineHandler.java:38) [ViaProxy.jar:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [ViaProxy.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.AdvancedChannelInboundHandler.channelRead(AdvancedChannelInboundHandler.java:48) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [ViaProxy.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientProxyRouteHandler.channelRead(RakClientProxyRouteHandler.java:50) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) [ViaProxy.jar:?]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) [ViaProxy.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) [ViaProxy.jar:?]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) [ViaProxy.jar:?]
	at io.netty.channel.nio.AbstractNioMessageChannel$NioMessageUnsafe.read(AbstractNioMessageChannel.java:97) [ViaProxy.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:788) [ViaProxy.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:724) [ViaProxy.jar:?]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:650) [ViaProxy.jar:?]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:562) [ViaProxy.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) [ViaProxy.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [ViaProxy.jar:?]
	at java.base/java.lang.Thread.run(Thread.java:833) [?:?]

Unknown Internet Protocol version error

When connecting to play.histeria.fr this error is thrown:

java.lang.UnsupportedOperationException: Unknown Internet Protocol version.
	at org.cloudburstmc.netty.util.RakUtils.readAddress(RakUtils.java:72) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOnlineInitialHandler.onConnectionRequestAccepted(RakClientOnlineInitialHandler.java:95) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOnlineInitialHandler.channelRead0(RakClientOnlineInitialHandler.java:81) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOnlineInitialHandler.channelRead0(RakClientOnlineInitialHandler.java:39) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.AdvancedChannelInboundHandler.channelRead(AdvancedChannelInboundHandler.java:48) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.AdvancedChannelInboundHandler.channelRead(AdvancedChannelInboundHandler.java:48) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.AdvancedChannelInboundHandler.channelRead(AdvancedChannelInboundHandler.java:48) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.common.RakSessionCodec.checkForOrdered(RakSessionCodec.java:325) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.common.RakSessionCodec.handleDatagram(RakSessionCodec.java:316) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.common.RakSessionCodec.channelRead(RakSessionCodec.java:207) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:102) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.handler.codec.MessageToMessageCodec.channelRead(MessageToMessageCodec.java:111) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOfflineHandler.channelRead0(RakClientOfflineHandler.java:115) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientOfflineHandler.channelRead0(RakClientOfflineHandler.java:38) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:99) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.AdvancedChannelInboundHandler.channelRead(AdvancedChannelInboundHandler.java:48) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at org.cloudburstmc.netty.handler.codec.raknet.client.RakClientProxyRouteHandler.channelRead(RakClientProxyRouteHandler.java:50) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.epoll.EpollDatagramChannel.connectedRead(EpollDatagramChannel.java:606) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.epoll.EpollDatagramChannel.access$400(EpollDatagramChannel.java:56) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.epoll.EpollDatagramChannel$EpollDatagramChannelUnsafe.epollInReady(EpollDatagramChannel.java:538) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:499) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:397) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997) ~[ViaProxy-3.0.19.jar:?]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) ~[ViaProxy-3.0.19.jar:?]
	at java.lang.Thread.run(Thread.java:1623) [?:?]

[v2] Connecting to play.inpvp.net does not work

The server seems to not like the RakNet protocol handling and disconnects the client (Observed with Wireshark). It did work with the old Network/Protocol library

[v2] Pinging servers does not work

Trying to send a RakPing results in it never being sent due to an exception.
Should be reproduceable by trying to send a RakPing to a server.

I got an error from reading a InetSocketAddress...

Stacktrace: https://pastebin.com/xmE0axx3

Prevent IP Fragmentation

Java does not support disabling IP fragmentation with the IP_DONTFRAG socket option which causes some networks and VPNs consistently not being able to connect due to how Raknet discovers MTU.

JBS Issue: https://bugs.openjdk.java.net/browse/JDK-8238725

Error `java.lang.UnsupportedOperationException: Reflective setAccessible(true) disabled` when using the `RakUtils` class

Error java.lang.UnsupportedOperationException: Reflective setAccessible(true) disabled when using the RakUtils class

While running my application that utilizes the CloudburstMC and Netty libraries, I encountered the following error:

java.lang.UnsupportedOperationException: Reflective setAccessible(true) disabled
    at org.cloudburstmc.netty.util.RakUtils.<clinit>(RakUtils.java:28)
    ...

The error seems to be due to an attempt to access the private constructor of the DefaultChannelPipeline class from Netty using reflection. This occurs in the RakUtils class of the CloudburstMC library.

Steps to Reproduce:

Integrate the CloudburstMC library into a project.
Try to execute a feature that uses the RakUtils class.

Relevant Code:
Snippet from the RakUtils class:

static {
    try {
        Constructor<DefaultChannelPipeline> constructor = DefaultChannelPipeline.class.getDeclaredConstructor(Channel.class);
        constructor.setAccessible(true);
        DEFAULT_CHANNEL_PIPELINE_CONSTRUCTOR = constructor;
    } catch (NoSuchMethodException e) {
        throw new AssertionError("Unable to find DefaultChannelPipeline(Channel) constructor", e);
    }
}

Environment:
Operating System: Windows, Linux, Debian
Java Version: 17
CloudburstMC Library Version: latest
Netty Version: latest

I am willing to provide additional information or conduct tests to resolve this issue.

Thank you !

Client-based 'Already Connected' bug

Hello, we are using this library on our proxy server. We noticed a client-based bug and we want to report it.

The customer sends the 1st connection request to RakNet and receives a reply, cannot process the request due to an error, and throws the 1st connection request again. RakNet calls it 'Already Connected' and remains on the game loading screen.

Packet analysis with Wireshark (left side failed, right side successful connection):

Client disconnection error

Closing raknet client usually causes whole raknet server to crash. Usually this is caused by thrown exception.

Thrown exception:

A task raised an exception. Task: com.nukkitx.network.raknet.RakNetClient$$Lambda$179/1494588403@e2a0cad
java.lang.NullPointerException: null
        at com.nukkitx.network.raknet.RakNetClient.lambda$onTick$1(RakNetClient.java:86) ~[waterdog-1.0.0-SNAPSHOT.jar:?]
        at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163) [waterdog-1.0.0-SNAPSHOT.jar:?]
        at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:510) [waterdog-1.0.0-SNAPSHOT.jar:?]
        at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:518) [waterdog-1.0.0-SNAPSHOT.jar:?]
        at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050) [waterdog-1.0.0-SNAPSHOT.jar:?]
        at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [waterdog-1.0.0-SNAPSHOT.jar:?]
        at java.lang.Thread.run(Unknown Source) [?:?]

Software implementation uses Protocol with 1.6.20 version of network components. It looks like this should be fixed in 1.6.21. Using self-compiled version of Protocol with 1.6.21 does't allow client event to open connection. By other words onSessionCreation() in server listener is not called. So I assume the 1.6.21 update broke something.

cloudburstmc / network Goto Github PK

network's People

Contributors

Stargazers

Watchers

Forkers

network's Issues

Recommend Projects

Recommend Topics

Recommend Org