Impact
PocketMine-MP currently does not limit the maximum number of unauthenticated sessions. Max player count is checked only when PlayerPreLoginEvent is reached. No problems so far.
On a 100-player server, an attacker can create 110 sessions, and never send the LoginPacket. These sessions won't be kicked as explained above (until a 10-second login timeout is reached). However, since these unauthenticated sessions are included for the max-players check, this means that any real player who sends a LoginPacket is immediately disconnected.
The solution to this is fairly simple: only include sessions in the max-players check which themselves have already passed a max-players check, i.e. sessions which have sent a LoginPacket. (Note that this is NOT the same as count(getOnlinePlayers()), as getOnlinePlayers() only includes connections for which a Player has been created.)
Patches
This problem has been fixed by 59be901.
Workarounds
A possible workaround is to increase the max player count of your server. This isn't a great solution, but it helps to mitigate the problem by making it harder to fill all the player slots. You can also un-cancel PlayerPreLoginEvent if the reason is SERVER_FULL (but beware of using getOnlinePlayers() for a replacement check, as this will allow your max-players to be exceeded in some cases).
Impact
PocketMine-MP currently does not limit the maximum number of unauthenticated sessions. Max player count is checked only when
PlayerPreLoginEventis reached. No problems so far.On a 100-player server, an attacker can create 110 sessions, and never send the
LoginPacket. These sessions won't be kicked as explained above (until a 10-second login timeout is reached). However, since these unauthenticated sessions are included for themax-playerscheck, this means that any real player who sends aLoginPacketis immediately disconnected.The solution to this is fairly simple: only include sessions in the max-players check which themselves have already passed a max-players check, i.e. sessions which have sent a
LoginPacket. (Note that this is NOT the same ascount(getOnlinePlayers()), asgetOnlinePlayers()only includes connections for which aPlayerhas been created.)Patches
This problem has been fixed by 59be901.
Workarounds
A possible workaround is to increase the max player count of your server. This isn't a great solution, but it helps to mitigate the problem by making it harder to fill all the player slots. You can also un-cancel
PlayerPreLoginEventif the reason isSERVER_FULL(but beware of usinggetOnlinePlayers()for a replacement check, as this will allow your max-players to be exceeded in some cases).