Open Leahcimkrob opened 11 months ago
I use the latest available version
Please try the following two things individually:
The problem is that the changes in 1.20.2 break A LOT of plugins, and break expected behavior in proxies, so it's not easy to just definitively say what it is
The first option doesn't make sense to me, so it's not acceptable, but it has to work like it used to. There has also been feedback in your Discord that it doesn't work either.
We have already tried the second one with the same error.
In my case, the players are getting instantly kicked with the 'Disconnected' message. ViaVersion is installed on the proxy. The following stacktrace is printed there
16:53:09 [INFO] [/[REDACTED]] <-> InitialHandler has connected
16:53:10 [INFO] [quiquelhappy] <-> ServerConnector [cool] has connected
16:53:10 [SEVERE] [quiquelhappy] -> UpstreamBridge - encountered exception
io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.Login in phase CONFIGURATION with direction TO_CLIENT
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:125)
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:881)
at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:940)
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:966)
at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:934)
at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1020)
at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:311)
at net.md_5.bungee.netty.ChannelWrapper.write(ChannelWrapper.java:85)
at net.md_5.bungee.UserConnection$1.sendPacket(UserConnection.java:152)
at net.md_5.bungee.ServerConnector.handleLogin(ServerConnector.java:246)
at net.md_5.bungee.ServerConnector.handle(ServerConnector.java:194)
at net.md_5.bungee.protocol.packet.Login.handle(Login.java:283)
at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:124)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:442)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:346)
at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:318)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:444)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:412)
at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:440)
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:420)
at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:800)
at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:509)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:407)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:997)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.Login in phase CONFIGURATION with direction TO_CLIENT
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:463)
at net.md_5.bungee.protocol.Protocol$DirectionData.getId(Protocol.java:824)
at net.md_5.bungee.protocol.MinecraftEncoder.encode(MinecraftEncoder.java:25)
at net.md_5.bungee.protocol.MinecraftEncoder.encode(MinecraftEncoder.java:10)
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107)
... 42 more
16:53:10 [INFO] [quiquelhappy] disconnected with: EncoderException : java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.Login in phase CONFIGURATION with direction TO_CLIENT @ io.netty.handler.codec.MessageToByteEncoder:125
It seems like on the 'subservers' (paper), the join event is even triggered and the player appears as connected for a brief moment, showing the 'Player x joined' and 'Player x left' messages.
I've also tried moving ViaVersions to the subservers (removing it from the proxy), and now get the following error:
It seems it might be related to https://github.com/NEZNAMY/TAB/releases/tag/4.0.4, I'll be testing it in few moments
After running into this myself, I was able to reproduce this in a newly created testing environment. (Bungeecord: git:BungeeCord-Bootstrap:1.20-R0.2-SNAPSHOT:49e4de7:unknown, ViaVersion: 4.8.0, No other proxy plugins, 1.12.2 backend server)
io.netty.handler.codec.EncoderException: java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.Login in phase CONFIGURATION with direction TO_CLIENT
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:125)
at io.netty.channel.AbstractChannelHandlerContext.invokeWrite0(AbstractChannelHandlerContext.java:881)
at io.netty.channel.AbstractChannelHandlerContext.invokeWriteAndFlush(AbstractChannelHandlerContext.java:940)
at io.netty.channel.AbstractChannelHandlerContext.write(AbstractChannelHandlerContext.java:966)
at io.netty.channel.AbstractChannelHandlerContext.writeAndFlush(AbstractChannelHandlerContext.java:934)
at io.netty.channel.DefaultChannelPipeline.writeAndFlush(DefaultChannelPipeline.java:1020)
at io.netty.channel.AbstractChannel.writeAndFlush(AbstractChannel.java:311)
at net.md_5.bungee.netty.ChannelWrapper.write(ChannelWrapper.java:90)
at net.md_5.bungee.UserConnection$1.sendPacket(UserConnection.java:171)
at net.md_5.bungee.ServerConnector.handleLogin(ServerConnector.java:254)
at net.md_5.bungee.ServerConnector.handle(ServerConnector.java:202)
at net.md_5.bungee.protocol.packet.Login.handle(Login.java:283)
at net.md_5.bungee.netty.HandlerBoss.channelRead(HandlerBoss.java:124)
<SNIP>
Caused by: java.lang.IllegalArgumentException: Cannot get ID for packet class net.md_5.bungee.protocol.packet.Login in phase CONFIGURATION with direction TO_CLIENT
at com.google.common.base.Preconditions.checkArgument(Preconditions.java:463)
at net.md_5.bungee.protocol.Protocol$DirectionData.getId(Protocol.java:848)
at net.md_5.bungee.protocol.MinecraftEncoder.encode(MinecraftEncoder.java:26)
at net.md_5.bungee.protocol.MinecraftEncoder.encode(MinecraftEncoder.java:10)
at io.netty.handler.codec.MessageToByteEncoder.write(MessageToByteEncoder.java:107)
... 40 more
I am not super familiar with how ViaVersion works, but.. after some debugging
it seems that the upstream (server) and the downstream (client) handler of
BungeeCord are out of sync with each other. BungeeServerHandler
correctly sets
the protocol of the upstream to 1.12.2 when trying to connect to the first
server, leading to a functional connection to the upstream. But at that point
the downstream handling is in 1.20.2 mode, and is in the configuration phase.
When the upstream handler then tries to complete the initial connection, this
error is thrown, as the Login (or "join game") packet is from the play/game
phase.
To me it seems that there is some code missing to basically fake the configuration phase to make BungeeCord and the client happy, before the play phase packets can be processed. But then again, I may be wrong, I am no expert.
I did not test connecting to a 1.20.2 upstream first, and then switching to a 1.12.2 backend. That might work, as that's not hitting this code path, but may very well still trigger in other ways. In case anyone is trying to find a workaround.
After updating some of my plugins, and updating both paper and bungeecord, this isn't happening to me anymore
I still have the problem. Paper, Geyser, Viaversion, Viarewind and Bungee are up to date For me it is not a solution to drag the plugins to the backend server, as the advantages of the bungee cord are then lost.
There is no benefit at all in running ViaVersion on the proxy other than having to place the jar multiple times. A lot of fixes are only available if run on the backend, and in general running on the proxy requires more complex handling of the client and puts more strain on it
Nevertheless, it's stupid when you have to update a plugin that previously always ran via the proxy on 6 servers because you can't manage it. Bungeecrod now also works with TAB and Geyser without errors. So it's up to you somewhere why you can no longer come online with smaller versions.
I can confirm I can't connect to Paper 1.20.1-196 with using Minecraft (1.20.2) to connect Waterfall (1.20) with ViaVersion (4.8.1). Adding ViaVersion into Paper server worked but it should work when adding it to Waterfall.
Kicked whilst connecting to lobby: Outdated server! I'm still on 1.20.1
Update waterfall.
I got the same problem but in mine it says that i can't connect with a version that is different from 1.18.2. Before the 1.20.2 release of bungee and viaversion this problem wasn't there. The hub is in 1.18.2, the survival is in 1.20.1, if i join with 1.20.1 it's all right, but when i try to join with 1.20.2 via versions says the error above (the version depends obv by the hub version)
Latest version of Via Version (+115) Latest version of Waterfall Latest version of Via Backwards (+65)
I got the same problem but in mine it says that i can't connect with a version that is different from 1.18.2. Before the 1.20.2 release of bungee and viaversion this problem wasn't there. The hub is in 1.18.2, the survival is in 1.20.1, if i join with 1.20.1 it's all right, but when i try to join with 1.20.2 via versions says the error above (the version depends obv by the hub version)
Latest version of Via Version (+115) Latest version of Waterfall Latest version of Via Backwards (+65)
To fix the problem the only way is to use via version and via backwards on all server, but before works perfect using it only on waterfall
I have the same problème every i can't connect to my waterfall server in every versions after the update... please patch this ;-; bfore viaversion work perfectly... and when i set the plugin on the Backen server i can't connect on 1.20.2 to i can just connect on 1.20.1 ...
There is no benefit at all in running ViaVersion on the proxy other than having to place the jar multiple times. A lot of fixes are only available if run on the backend, and in general running on the proxy requires more complex handling of the client and puts more strain on it
There is a benefit in running ViaVersion on the proxy, especially for large networks where the admins could update only once after a new update is released rather than repeating the same operation on all backends. Also, if some behaviors were changed on the proxy for a long time, they should be adapted even if they seem to be broken.
ViaVersion for 1.20.2 on Waterfall has been broken for two months and moving the plugin with its configuration to backends would only increase the maintenance cost for most servers, many servers have to move the plugin and its configuration to backends just to make sure their network is playable on 1.20.2.
Please do something about this issue.
That benefit is to a problem not unique to ViaVersion, and the reason that it runs on the proxy is not to make distribution easier. Large servers should have a templating system to allow for updating processes to be streamlined and not depend on Via running worse in every other way due to constraints that come with a proxy, especially Bungee
Eitherway, please try updating ViaVersion to builds from https://ci.viaversion.com/job/ViaVersion-DEV/ as those have some important fixes to its state handling which should help, and make sure Waterfall and other proxy plugins are up to date as well
/viaversion dump
Outputhttps://dump.viaversion.com/63cee61c1812b872d101ebc7cf9c401001d12c09de70d42503b0a384e2787422
Console Error
Bug Description
When I try to access the server with version 1.20.2 I get the message connection aborted
I hate this wrangling of authority. You say, Bungee's problem, Bungee says it's your business and I as a dev who would like to use your crap is the idiot. If there are problems, just try to solve them together and not just blame each other. It would help everyone in the MC world.
Steps to Reproduce
When I try to access the server with version 1.20.2 I get the message connection aborted
Expected Behavior
When I try to access the server with version 1.20.2 I get the message connection aborted
Additional Server Info
Via only on Bungee
Plugins: BetterSecurity, BungeeChat, BungeePluginManagerPlus, BungeeSpy, BungeeTokens, CensorReloaded, CMIB, CraftingStore, DSGVO, ExceptionAnnouncer, floodgate, Geyser-BungeeCord, LiteBans, LuckPerms, Maintenance, MarriageMaster, NoVPN, NuVotifier, RankGift, RankUpgrade, spark, TAB, UltimateAutoRestartPassthrough, ViaBackwards, ViaVersion, cmd_alert, cmd_find, cmd_kick, cmd_list, cmd_send, cmd_server, reconnect_yaml.
Checklist