Describe the bug
Disconnecting players (kick or quit quit witout properly hitting disconnect can break the server.
It gets unjoinable until restart of the bungee / standalone Geyser.
Old connections will still be ingame.
To Reproduce
Enable ping-passthrough and use any motd on the server-side.
Join with two players (quitting or rejoin exploits needs more than 1 player).
Quit game.
Rejoin right after that (best before your copy disappears).
The server gets crushed.
Expected behavior
Being able to join again.
Screenshots / Videos
On the clientside you will just see:
_java.io.IOException: An established connection was aborted by the software in your host machine._
or more often just a
_Disconnected_
and sometimes a
_java.io.IOException: An existing connecion was forcibly closed by the remote host_
Server Version
bungee 1.15 snapshot
paper 205
Geyser Version
1.0 snapshot build 90
Minecraft: Bedrock Edition Version
1.14.6
Additional Context
You need to restart the Geyser or the Server on the other side to connect again.
potential temporary fixes:
detect the line in the server log and kill a proxy in front of geyser.
use multiple geysers/frontproxies and hope players dont leave.
make players aware to always close the game.
Please fix this. it's a huge issue.
Thanks
It gets unjoinable.
You need to restart the Geyser or the Server on the other side to connect again.
On the clientside you will just see:
java.io.IOException: An established connection was aborted by the software in your host machine.Please fix this.
Thanks
Please follow the issue template.
Unable to reproduce. Please make sure you're using the latest version of Geyser and make sure there are no errors in console. If there are errors in console, please provide that here.
aborted by the software:
https://bpaste.net/raw/LDXQ
https://bpaste.net/raw/KZSQ
forcibly closed by the host (tried with a different ip):
https://bpaste.net/raw/7SDA
When i try to login i also get spammed by
"please wait until you login" and then kicked with the exception
it currently occurs in the plugin version (so it makes a whole bungee-resatrt necessary), but was also existent in the standalone.
Same problem, this can happen when client crashes, so players aren't kicked out properly, but I think this is normal, for the server didn't get the disconnect package, waiting till the timeout time and join again will be ok
Same problem, this can happen when client crashes, so players aren't kicked out properly, but I think this is normal, for the server didn't get the disconnect package, waiting till the timeout time and join again will be ok
what's your timeout time? when i tried to rejoin my server after a few hours it seemed to work again. but not for at least 40 minutes...
For me 5 minutes is the longest, you can try to update geyser, I think this happened before, but not now for I'm using the latest version of geyser
For me 5 minutes is the longest, you can try to update geyser, I think this happened before, but not now for I'm using the latest version of geyser
i cant reproduce that, it will always get stuck with a fake +1 playercount.
geyser reload doesnt fix it btw but instead breaks ping forwarding (and such forces geyser to show its own motd etc)
the only way to prevent the nonjoinability atm is setting up a script that checks the logs and kills the proxy when the server breaks :/
you should put an announcer up too, encouraging users to not close the app but instead use the disconnect button to quit and that the server sometimes crashes due to the technology used or something.
this bug is critical and means a single user can dos/crush a server by simply quitting wrong.
@RednedEpic it also happens when people rejoin too fast after quitting in general. additional to forceclosing the app.
normal timing out will also cause this.
there's no way you can not reproduce this.
it's a horrible bug/exploit and it _will_ get abused if players find it out.
also it's kinda unfair for players on the server to kill the proxy, those disconnecting them, in order to allow new connections. the only way i can currently see would be running thousands of portbalanced standalone geyser-instances and only assigning one to each player and restarting one when they break, but that cant be a solution.
even if not, a crashing game or players forcequitting is nothing incommon with such a unoptimized and mobile app, especially on iOS.
@RednedEpic it also happens when people rejoin too fast after quitting in general. additional to forceclosing the app.
normal timing out will also cause this.there's no way you can not reproduce this.
it's a horrible bug/exploit and it _will_ get abused if players find it out.
also it's kinda unfair for players on the server to kill the proxy, those disconnecting them, in order to allow new connections. the only way i can currently see would be running thousands of portbalanced standalone geyser-instances and only assigning one to each player and restarting one when they break, but that cant be a solution.
even if not, a crashing game or players forcequitting is nothing incommon with such a unoptimized and mobile app, especially on iOS.
Unable to reproduce. Tried joining with Bedrock through Geyser, force closed the app and was able to join back perfectly fine before I was timed out by the server. Tried joining again after the server timed me out and was still able to get in without any problems.
@RednedEpic it also happens when people rejoin too fast after quitting in general. additional to forceclosing the app.
normal timing out will also cause this.
there's no way you can not reproduce this.
it's a horrible bug/exploit and it _will_ get abused if players find it out.
also it's kinda unfair for players on the server to kill the proxy, those disconnecting them, in order to allow new connections. the only way i can currently see would be running thousands of portbalanced standalone geyser-instances and only assigning one to each player and restarting one when they break, but that cant be a solution.
even if not, a crashing game or players forcequitting is nothing incommon with such a unoptimized and mobile app, especially on iOS.Unable to reproduce. Tried joining with Bedrock through Geyser, force closed the app and was able to join back perfectly fine before I was timed out by the server. Tried joining again after the server timed me out and was still able to get in without any problems.
did you try joining with another device after doing the exploit?
i just repeated and it let me rejoin after doing so on the attacker device, but the second device said
_java.io.IOException: An established connection was aborted by the software in your host machine._
i'm also using Bungee, so i couldnt rejoin while while my not-yet timeouted clone wasstill connected. i was also able to join, but not the second device, please verify if that works for you (different account maybe). thanks
@RednedEpic it also happens when people rejoin too fast after quitting in general. additional to forceclosing the app.
normal timing out will also cause this.
there's no way you can not reproduce this.
it's a horrible bug/exploit and it _will_ get abused if players find it out.
also it's kinda unfair for players on the server to kill the proxy, those disconnecting them, in order to allow new connections. the only way i can currently see would be running thousands of portbalanced standalone geyser-instances and only assigning one to each player and restarting one when they break, but that cant be a solution.
even if not, a crashing game or players forcequitting is nothing incommon with such a unoptimized and mobile app, especially on iOS.Unable to reproduce. Tried joining with Bedrock through Geyser, force closed the app and was able to join back perfectly fine before I was timed out by the server. Tried joining again after the server timed me out and was still able to get in without any problems.
did you try joining with another device after doing the exploit?
i just repeated and it let me rejoin after doing so on the attacker device, but the second device said
java.io.IOException: An established connection was aborted by the software in your host machine.i'm also using Bungee, so i couldnt rejoin while instantly while my not-yet timeouted close was connected. i was also able to join, but not the second device, please verify if that works for you (different account maybe). thanks
Just tested this and can confirm that using bungeecord and 2 different accounts/devices causes it to break
@RednedEpic it also happens when people rejoin too fast after quitting in general. additional to forceclosing the app.
normal timing out will also cause this.
there's no way you can not reproduce this.
it's a horrible bug/exploit and it _will_ get abused if players find it out.
also it's kinda unfair for players on the server to kill the proxy, those disconnecting them, in order to allow new connections. the only way i can currently see would be running thousands of portbalanced standalone geyser-instances and only assigning one to each player and restarting one when they break, but that cant be a solution.
even if not, a crashing game or players forcequitting is nothing incommon with such a unoptimized and mobile app, especially on iOS.Unable to reproduce. Tried joining with Bedrock through Geyser, force closed the app and was able to join back perfectly fine before I was timed out by the server. Tried joining again after the server timed me out and was still able to get in without any problems.
did you try joining with another device after doing the exploit?
i just repeated and it let me rejoin after doing so on the attacker device, but the second device said
java.io.IOException: An established connection was aborted by the software in your host machine.
i'm also using Bungee, so i couldnt rejoin while instantly while my not-yet timeouted close was connected. i was also able to join, but not the second device, please verify if that works for you (different account maybe). thanksJust tested this and can confirm that using bungeecord and 2 different accounts/devices causes it to break
2 different devices means any account / any new connection btw (the attacker seems to be fine, didnt try out with 3 devices yet if other people that were on the server when the attack happened can still rejoin)
Seems to be very intermittent, only happens sometimes for me.
Edit: I've only got it to occur once, maybe a fluke?
Seems to be very intermittent, only happens sometimes for me
java.io.IOException: An established connection was aborted by the software in your host machine.
or more often just a
Disconnected
and sometimes a
java.io.IOException: An existing connecion was forcibly closed by the remote host
yeah the results are random, but mostly caused by timing out and result in the server not being joinable for new connections
trust me, any timeout could cause this, i recently got a new ip on my device and after timing out myself it broke the server for me. i currently see it as the biggest weakness of Geyser as i'm not a fan of exploits where a single users can break a server by doing such a ridiculous thing as quitting the app and leaving the connection open or such.
I'm having the same issue occasionally. Here's my console ~ https://pastebin.com/YFjfNwt7
@Artuto this is not "after a while", there's more than 1 way to trigger this instantly.
Also the exceptions are different and never throw a broken pipe message
I'll try disabling the pingthrough and see if it will still break though.
Yeah, I have it sometime, need to kick the player manually to fix it
Yeah, I have it sometime, need to kick the player manually to fix it
Which one, the timedout one? How? Do you have a Bungee-Plugin for that, do you do ot on Geysers side (i dont remember a geyser kick command) or do you just disconnect his ip:port connection via the system? If its easy like that, you could just write a system script that continuously analyzes the log, writes the ip and port of every joined-via-geyser player into some database and then when it sees user timed out, kills that connection.
Yeah, I have it sometime, need to kick the player manually to fix it
Which one, the timedout one? How? Do you have a Bungee-Plugin for that, do you do ot on Geysers side (i dont remember a geyser kick command) or do you just disconnect his ip:port connection via the system? If its easy like that, you could just write a system script that continuously analyzes the log, writes the ip and port of every joined-via-geyser player into some database and then when it sees user timed out, kills that connection.
I'm using bungeecord version, and just kick player manually can fix this
It seems player isn't in the geyser list, but in bungee list, this's weird
Yeah, I have it sometime, need to kick the player manually to fix it
Which one, the timedout one? How? Do you have a Bungee-Plugin for that, do you do ot on Geysers side (i dont remember a geyser kick command) or do you just disconnect his ip:port connection via the system? If its easy like that, you could just write a system script that continuously analyzes the log, writes the ip and port of every joined-via-geyser player into some database and then when it sees user timed out, kills that connection.
I'm using bungeecord version, and just kick player manually can fix this
It seems player isn't in the geyser list, but in bungee list, this's weird
So it may just be an issue on the backend server not seeing the client disconnected correctly. Well, this explains why the backend playercount was still 1 even if nobody was connected. So we either have to rely on the geyser ppl to implement that kick in the bungee plugin or create such a plugin on our own. But i dont think geyser has a event api. And im shite with java so i dont even know where to start for the kick command.
Yeah, I have it sometime, need to kick the player manually to fix it
Which one, the timedout one? How? Do you have a Bungee-Plugin for that, do you do ot on Geysers side (i dont remember a geyser kick command) or do you just disconnect his ip:port connection via the system? If its easy like that, you could just write a system script that continuously analyzes the log, writes the ip and port of every joined-via-geyser player into some database and then when it sees user timed out, kills that connection.
I'm using bungeecord version, and just kick player manually can fix this
It seems player isn't in the geyser list, but in bungee list, this's weirdSo it may just be an issue on the backend server not seeing the client disconnected correctly. Well, this explains why the backend playercount was still 1 even if nobody was connected. So we either have to rely on the geyser ppl to implement that kick in the bungee plugin or create such a plugin on our own. But i dont think geyser has a event api. And im shite with java so i dont even know where to start for the kick command.
Yes, this is the problem, and geyser don't provide an API, so we can't just compare the player list in bungee with the list in geyser, we need a alternative way
@AnonAlpha the ip command says the player isnt connected when he timed out. tcpview isnt really helpful here either. are you sure the connection is still open? i cannot replicate that, the only thing i can do is instantly breaking the geyser/bungee connection handler and leaving it like this.
Yo @RednedEpic did you have time to reproduce this yet? Autorestarting the bungee whenever a user timeouts belongs to the pocketmine-era
I can reproduce this but not consistently, it seems almost random, will do some more testing
@blubbll, do you use ping-passthrough?

@blubbll, do you use ping-passthrough?
well yes. I'll now try to break it again without the passthrough though.
@blubbll, do you use ping-passthrough?
well yes. I'll now try to break it again without the passthrough though.
@CuteTadpole Sorry for the delay, my server had a networking issue so i couldn't test it out live earlier.
I cannot seem to break the geyser with pingthrough disabled. I never thought of disabling that lol.
Thanks. Not sure if i can close the issue though, as it seems to be related to ping-passthrough.
I also tried it without BungeeMOTD+, using the default motd from the bungee config.yml and passthrough enabled, leaving still breaks geyser. So i'll update the issue above and disable passthrough for now.
Thanks again for helping me find a different fix than restarting the server when the log detects a timeout lol.
So now we know why this bug happens. @blubbll, thank you for testing!
Should you have time, could you try with build #468?
@CuteTadpole go to the PR, go to checks, and click on Artifacts in the top-right.
Got this error after 5 times of quiting/joining:
[21:32:51 INFO] /192.168.1.245:49486 tried to connect!
[21:32:51 INFO] Player connected with username CuteTadpole
[21:32:57 INFO] Attempting to login using offline mode... authentication is disabled.
[21:32:57 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1
[21:32:57 INFO] CuteTadpole has disconnected from remote java server on address 127.0.0.1 because of Connection closed.
[21:42:57 INFO] Bedrock user with ip: /192.168.1.245 has disconnected for reason CLOSED_BY_REMOTE_PEER
[21:43:11 INFO] /192.168.1.245:49486 tried to connect!
[21:43:12 INFO] Player connected with username CuteTadpole
[21:33:18 INFO] Attempting to login using offline mode... authentication is disabled.
[21:43:18 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1
[21:43:18 INFO] CuteTadpole has disconnected from remote java server on address 127.0.0.1 because of Connection closed.
[21:43:18 INFO] Bedrock user with ip: /192.168.1.245 has disconnected for reason CLOSED_BY_REMOTE_PEER
and then I can't join to this server...
but waiting ~1 min I again can connect to the server
And this is with passthrough MOTD enabled and legacy ping passthrough disabled?

Disable legacy-ping-passthrough and try again.
Got this error after 5 times of quiting/joining:
[21:32:51 INFO] /192.168.1.245:49486 tried to connect! [21:32:51 INFO] Player connected with username CuteTadpole [21:32:57 INFO] Attempting to login using offline mode... authentication is disabled. [21:32:57 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1 [21:32:57 INFO] CuteTadpole has disconnected from remote java server on address 127.0.0.1 because of Connection closed. [21:42:57 INFO] Bedrock user with ip: /192.168.1.245 has disconnected for reason CLOSED_BY_REMOTE_PEER [21:43:11 INFO] /192.168.1.245:49486 tried to connect! [21:43:12 INFO] Player connected with username CuteTadpole [21:33:18 INFO] Attempting to login using offline mode... authentication is disabled. [21:43:18 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1 [21:43:18 INFO] CuteTadpole has disconnected from remote java server on address 127.0.0.1 because of Connection closed. [21:43:18 INFO] Bedrock user with ip: /192.168.1.245 has disconnected for reason CLOSED_BY_REMOTE_PEERand then I can't join to this server...
but waiting ~1 min I again can connect to the server
do you have the referenced version's jar? i suck at working with / compiling java stuff and i'd also like to try if this fixed this issue. thanks
@blubbll go to PR #468, go to checks, and click on Artifacts in the top-right.
Make sure you are not testing with legacy ping passthrough - that is the old ping passthrough that breaks.
[21:59:06 INFO] /192.168.1.245:44151 tried to connect!
[21:59:07 INFO] Player connected with username CuteTadpole
[21:59:13 INFO] Attempting to login using offline mode... authentication is disabled.
[21:59:13 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1
[21:59:13 INFO] CuteTadpole has disconnected from remote java server on address 127.0.0.1 because of Connection closed.
[21:59:13 INFO] Bedrock user with ip: /192.168.1.245 has disconnected for reason CLOSED_BY_REMOTE_PEER
[21:59:25 INFO] /192.168.1.245:44151 tried to connect!
[21:59:25 INFO] Player connected with username CuteTadpole
[21:59:31 INFO] Attempting to login using offline mode... authentication is disabled.
[21:59:31 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1
[21:59:31 INFO] Registering bedrock skin for CuteTadpole (bb1316fc-8a31-336c-a14f-d01261effcb7)
[21:59:31 INFO] Unable to load bedrock skin for 'CuteTadpole' as they are likely using a customised skin
[21:59:32 INFO] Spawned player at 2.2803164 90.0 0.9967752999999999
Got this error 1 time and then error dissapears. I think, this PR really works.
We need to wait blubbll's comment.
[21:59:06 INFO] /192.168.1.245:44151 tried to connect! [21:59:07 INFO] Player connected with username CuteTadpole [21:59:13 INFO] Attempting to login using offline mode... authentication is disabled. [21:59:13 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1 [21:59:13 INFO] CuteTadpole has disconnected from remote java server on address 127.0.0.1 because of Connection closed. [21:59:13 INFO] Bedrock user with ip: /192.168.1.245 has disconnected for reason CLOSED_BY_REMOTE_PEER [21:59:25 INFO] /192.168.1.245:44151 tried to connect! [21:59:25 INFO] Player connected with username CuteTadpole [21:59:31 INFO] Attempting to login using offline mode... authentication is disabled. [21:59:31 INFO] CuteTadpole (logged in as: CuteTadpole) has connected to remote java server on address 127.0.0.1 [21:59:31 INFO] Registering bedrock skin for CuteTadpole (bb1316fc-8a31-336c-a14f-d01261effcb7) [21:59:31 INFO] Unable to load bedrock skin for 'CuteTadpole' as they are likely using a customised skin [21:59:32 INFO] Spawned player at 2.2803164 90.0 0.9967752999999999Got this error 1 time and then error dissapears. I think, this PR really works.
We need to wait blubbll's comment.
Yeah, this seems to work. Glad that ping-passthrough can be used again and will no longer result in a blocked server caused by timeout'ed connections.
The only thing that i now got when i rejoined after forcequitting the app was the "Already connected to the proxy", but it fixes itself after a few seconds (when the timeout actually hits).
gg