こんにちは、今回はGeyserの接続で、無駄に時間を費やした事を書きます。
原因判明後、ものの数分で解決できたので、本当に時間を無駄にしたな…って。
何があったんだい
超簡潔に話すと、VelocityサーバーをやめてSpigotサーバーのみにしました。
その時、GeyserをSpigotサーバーに入れて接続テストしましたが、接続できませんでした。
メッセージとして「Java版のアカウントとしてログインしようとしました。Floodgateは正しく設定されていますか？」というKickメッセージがありました。
コンソールログには、接続しようとしたログが流れていて、FloodGateもしっかり接続を認識して処理を実行できているようなのですが、エラーとしてKickされてしまいます…
当然ですが、Java版ではログインできますし、ポート開放もしてあります。
設定やGeyserの「auth-mode」も「floodgate」になっていて全て正しいはずです。
試したこと
とりあえずjarをダウンロードしなおし
もしかしたら、今のjarファイルが悪いのかもしれないと考えました。
一応ダウンロードしなおして、jarファイルを置き換えて再実行。
ただ、やっぱり治りませんでした…
key.pemが悪い？
次に、key.pemが悪いんじゃねって事で消して再実行してみました。
ただ、同様に治りませんでした…
configリセット
Geyserとfloodgateのフォルダを消して再実行。
そしてconfigをすべて設定しなおして再起動してテスト。
これでもやっぱり駄目でした…
server.propertiesの見直し
サーバーの設定の「enforce-secure-profile」や「use-native-transport」をoffにしてみる。
再起動後テストしてみますが、やっぱり駄目でした。
ポートの変更とclone-portのoff
Java版のサーバーと同じポートではいけないのでは、と考えてもみました。
そのため、統合版のポートを変更して、clone-portのオプションをオフにして再起動。
テストしてみますが、やはり無理でした。
解決の糸口
日本語で調べても全く何もわからず、情報がありません。
ドキュメントを見てもそれっぽい情報はなく、非常に困っていました。
ただ、英語で調べてみるとある1つのそれっぽいページを発見！
それが、FastLoginというプラグインのGithubのissuesです。
プラグイン自体はGeyserと関係ないみたいなのですが…
issuesの内容はGeyserにも関係するようで、これが解決の糸口になりました。
issuesを読み進めていくととあるメッセージを見つけました。
Please use BungeeCord or ProtocolSupport. The implementation for integration with ProtocolLib requires the cancellation and later re-submission of the client packet. Floodgate/Geyser intercept the packets too early in the process to see the cancellation. Fixing requires all of refactoring to only hold the first packet instead of cancel it. However many things needs to be considered, because the packet needs to be hold the complete login process. Things like timeout, session matching and more.
I’m open for any contribution as a pull request, but I don’t have the time for a free hobby project.
games647
In the past few days, I spent some time debugging the ProtocolLib and Floodgate sources in connection with #689 and I might have a better way to detect Floodgates players. Currently, FastLogin checks the players names, and since spaces get replaced in the names, the algorithm screws up. The netty
Smart123sChannelon which the player/packet is sent through contains an attributeFloodgatePlayerImplfor Floodgate players. Unfortunately, ProtocolLib doesn’t give any way to access the channel “of” a packet. My plan is to use Reflections to bypass some access modifiers (ProtocolLib and Floodgate does the same things in certain places), but we’ll see how it goes, as that solution is extremely unsafe, and requires precision to be reliable. But it would be still better than using names. This is just a plan for now, I can’t grantee that it’ll actually work, or that it’ll be reliable enough to be used.
これらを要約すると、ProtocolLibが問題である、ということだと思われます。
技術的な補足
どうやら名前の「スペース」つまり空白が「_」つまりアンダーラインに置き換わることが原因で発生するみたいであり、nettyの「FloodgatePlayerImpl」属性にその情報が含まれているが、ProtocolLibはそれにアクセスする方法が無いみたいです。
私の解釈があっているかわかりませんが、私はこう理解しました。
これに関しては、サーバーの参加時の処理が問題です。
これをどうするかというと、プロキシ側で事前に処理できるようにします。
つまり…結局Velocityサーバーを挟んでGeyserを使う必要があるということです。
解決
結局Velocityサーバーを挟むように仕様を戻して、接続できるようになりました！
まさかProtocolLibやそれに関連するプラグインが原因であるとは思いもしませんでした。
実際にProtocolLibが原因かは不明です！
私の認識では、その可能性が高いと考えているだけです！
最後に
いかがでしたか？
どうしても解決できないときは、ProtocolLibやそれの依存関係を消してみてください。
また、もしかしたら他のProtocol系APIもだめかもしれないので、消して試してください。
(例えば、HamsterAPIとかもProtocol系のAPIの一つですね。)
もし消して治ったなら、それはProtocol系のプラグインをあきらめるか、Velocityサーバーを用意してそこにGeyserやFloodGateを入れるしかないということになります。
それで治らないなら別のプラグインが原因である可能性や、別の設定等が原因であると思われます。
この記事が少しで役に立てれば幸いです…！
では！
コメント