1. Welcome to the Starbound support forums. Please check the support FAQs before posting: http://playstarbound.com/support

Bug/Issue SEVERE issue with Starbound Server mode

Discussion in 'Starbound Support' started by Alynna, Oct 6, 2016.

  1. Alynna

    Alynna Scruffy Nerf-Herder

    I host a starbound server, and have been encountering an issue that is making it very difficult to continue keeping it up.

    Basically what happens is when a non-starbound connection, connects to a port (usually a port scanner), and sends random or semi-random data, Starbound handles it very poorly:

    1) It does not drop the connection, and since my server is on a public IP address that gets hit many times a day by random port scanners, this fills up the player connection table until it no longer accepts connections
    2) When the data is sent to the socket, it logs that there was an decompression error from the connection (Error -3) and then instead of dropping the connection, the thread its in goes to 100% CPU, eventually using all CPU time on the server and lagging EVERYTHING DOWN, also CPU load on the server goes to 10.

    This is the relevant snippet of log:
    [08:29:02.862] [Info] UniverseServer: Connection received from: 0000:0000:0000:0000:0000:ffff:c17c:bebb:54599
    [08:29:02.874] [Warn] I/O error in TcpPacketSocket::readPackets, closing: (IOException) Internal error in uncompressData, inflate_res is -3
    [08:29:02.874] [Warn] UniverseServer: client connection aborted, expected ProtocolRequestPacket

    I believe that whatever handlles the ProtocolRequestPacket at the beginning of the session, does not properly close the connection when it gets bad data and who knows what causes it to go to 100% CPU.

    I have temporarily resolved the issue by running a cron daemon that checks the Starbound process and restarts it when CPU hits 300%. Needless to say my players don't like this. Not to mention it is trivial to DDoS the starbound server just by connecting to it a few times with netcat and sending ramdom data to it, or even just opening the connection without closing it. I can't tell the general internet to stop portscanning my box either, so its something that really needs to be fix in the code.

    The specs of the server are as follows:
    Intel i7-3770k 3.7ghz, 32gb RAM.
    Running starbound_server in console mode, no graphics.
    Linux 4.4.0 (Ubuntu 16.04 server) 64 bit
    Starbound is running and storing data to a 256GB SSD.

    Oh, and: [07:16:08.769] [Info] Server Version 1.1.1 (linux x86_64) Source ID: 82604f6097b124f2ed38ee58a7ae18c51e916dd8 Protocol: 724
     
  2. ambagesia

    ambagesia Intergalactic Tourist

    I hope this isn't too necro-y, but I'm also running into this issue.

    Relevant log snippet:
    [18:12:38.322] [Info] UniverseServer: Connection received from: 0000:0000:0000:0000:0000:ffff:01ae:660d:57677
    [18:12:38.324] [Warn] I/O error in TcpPacketSocket::readPackets, closing: (IOException) Internal error in uncompressData, inflate_res is -3
    [18:12:38.325] [Warn] UniverseServer: client connection aborted, expected ProtocolRequestPacket

    These happen a few times an hour. I know my server gets pinged a bajillion times a day by random bots looking for an easy way in, and I have strict iptables rules set for pretty much everything, but the port I run Starbound on is open so friends can connect to it without me having to whitelist them every time they're playing at a friend's house or something. It causes huge amounts of lag even when it's just me playing, and if I have more than 3-4 people on the server and it gets hit by more than 1-2 of these, I have to restart it.

    Server specs are:
    Running server in console mode
    Debian 8 (jessie) 64-bit, Linux 3.2.0
    Box has 4GB RAM/40GB disk space (and is only running this Starbound server currently)
    [Info] Server Version 1.3.2 (linux x86_64) Source ID: 4d70cfed23093a8e5abe06d662c6a5610fefc596 Protocol: 743
    NB: I'm running the FrackinUniverse mod, but this has been happening since before I installed it.

    Would really appreciate any info on whether there's a workaround for this or if it's just something I'm gonna have to deal with with an iptables whitelist.
     
    Last edited: Aug 29, 2017

Share This Page