Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Login with Client 1.20.2 not possible #2

Open
4 tasks done
Leahcimkrob opened this issue Sep 23, 2023 · 19 comments
Open
4 tasks done

Login with Client 1.20.2 not possible #2

Leahcimkrob opened this issue Sep 23, 2023 · 19 comments

Comments

@Leahcimkrob
Copy link

Leahcimkrob commented Sep 23, 2023

/viaversion dump Output

https://dump.viaversion.com/63cee61c1812b872d101ebc7cf9c401001d12c09de70d42503b0a384e2787422

Console Error

https://gist.github.com/Leahcimkrob/24be0fad486b65a4c4ddb858eb24cfb2

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

  • Via plugins are only running on EITHER the backend servers (e.g. Paper) OR the proxy (e.g. BungeeCord), not on both.
  • I have included a ViaVersion dump.
  • If applicable, I have included a paste (not a screenshot) of the error.
  • I have tried the latest build(s) from https://ci.viaversion.com/ and the issue still persists.
@Barvalg
Copy link
Member

Barvalg commented Sep 23, 2023

Platform: git%3ABungeeCord--Bootstrap%3A1.20--R0.2--SNAPSHOT%3A0509303%3A1738
Proxy is 1 builds behind
ViaVersion (4.8.0): 1 commits behind master

Please try the latest build(s) from https://ci.viaversion.com/. In case the issue still persists send the new dump

@Leahcimkrob
Copy link
Author

I use the latest available version

@kennytv
Copy link
Member

kennytv commented Sep 23, 2023

Please try the following two things individually:

  • Move Via plugins to the backend servers
  • Remove your other Bungee plugins
    and see if the issue persists

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

@Leahcimkrob
Copy link
Author

Leahcimkrob commented Sep 23, 2023

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.

@quiquelhappy
Copy link

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.

@quiquelhappy
Copy link

I've also tried moving ViaVersions to the subservers (removing it from the proxy), and now get the following error:
image

@quiquelhappy
Copy link

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

@killme
Copy link

killme commented Sep 24, 2023

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.

@quiquelhappy
Copy link

After updating some of my plugins, and updating both paper and bungeecord, this isn't happening to me anymore

@Leahcimkrob
Copy link
Author

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.

2023-09-30_09 08 10

@kennytv
Copy link
Member

kennytv commented Sep 30, 2023

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

@Leahcimkrob
Copy link
Author

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.

@cwchristerw
Copy link

cwchristerw commented Oct 23, 2023

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

@Kichura
Copy link
Member

Kichura commented Oct 30, 2023

Update waterfall.

@RelumCommunity
Copy link

RelumCommunity commented Nov 11, 2023

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)

@RelumCommunity
Copy link

RelumCommunity commented Nov 11, 2023

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

@ShuNeko
Copy link

ShuNeko commented Nov 24, 2023

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 ...

@MATRIX-feather
Copy link

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.

@kennytv
Copy link
Member

kennytv commented Dec 4, 2023

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

@kennytv kennytv transferred this issue from ViaVersion/ViaVersion May 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants