1. Смена портов помогла!
    Changing ports helped!
     
  2. Предлагаешь IP сервера сменить фактически?
    You suggest IP-server actually change?
     
  3. 185.71.1.25:27015 -> 185.71.1.25:27017

    Me ddos 109.171.67.55
    Rcon breaks 185.14.28.168
     
  4. why this spamming error if only on the modded servers? is this an oxide vulnerability?
    many servers at same time has this error.
     
  5. Wulf

    Wulf Community Admin

    Oxide doesn't handle any of the networking in Rust. Oxide does however show more messages that Rust doesn't in its console, so it could very well be affecting all servers without them knowing.
     
  6. Code:
    UnityEngine.Debug.LogWarning("[SERVER][UNHANDLED] " + packet.type);
    it's in ServerMgr.
    What does it mean? Maybe Oxide team can fix it themselves?)
     
  7. Wulf

    Wulf Community Admin

    You can hide it in your console using a plugin like FilterExt, but the warning is there as someone is sending invalid packets to the server most likely.
     
  8. I will try, thank you. But, if it doesn't help, can we filter invalid packets themselves, without Rust Devs?
     
  9. Wulf

    Wulf Community Admin

    They are already being ignored pretty much from what I can tell, which is why you see the warning.
     
  10. I am disappointed to hear it. Thank you for the care about us :)
     
  11. I sent to Facepunch support some info about this problem with proof of concept.
    Waiting for answer...
     
  12. It does'nt really look like Oxide related or caused by it. The message is generated by the Rust ServerMgr function "OnNetworkMessage":
    Code:
    // ServerMgr
    private void OnNetworkMessage(Message packet)
    {
    Message.Type type = packet.type;
    switch (type)
    {
    case Message.Type.RPCMessage:
        if (!packet.connection.isAuthenticated)
        {
            return;
        }
        using (TimeWarning.New("OnRPCMessage", 20L))
        {
            this.OnRPCMessage(packet);
        }
        return;
    case Message.Type.EntityPosition:
    case Message.Type.ConsoleMessage:
    case Message.Type.Effect:
    case Message.Type.Message:
    case Message.Type.RequestUserInformation:
        IL_3A:
        switch (type)
        {
        case Message.Type.Auth:
            if (packet.connection.state != Connection.State.Welcoming)
            {
                return;
            }
            using (TimeWarning.New("OnClientAuth", 20L))
            {
                this.OnClientAuth(packet);
            }
            return;
        case Message.Type.Ready:
            if (!packet.connection.isAuthenticated)
            {
                return;
            }
            using (TimeWarning.New("ClientReady", 20L))
            {
                this.ClientReady(packet);
            }
            return;
        }
        Debug.LogWarning("[SERVER][UNHANDLED] " + packet.type);
        return;
    case Message.Type.ConsoleCommand:
        if (!packet.connection.isAuthenticated)
        {
            return;
        }
        using (TimeWarning.New("OnClientCommand", 20L))
        {
            ConsoleNetwork.OnClientCommand(packet);
        }
        return;
    case Message.Type.DisconnectReason:
    {
        string str = packet.read.String();
        Debug.Log(packet.connection.ToString() + " disconnecting: " + str);
        return;
    }
    case Message.Type.Tick:
        if (!packet.connection.isAuthenticated)
        {
            return;
        }
        using (TimeWarning.New("OnPlayerTick", 20L))
        {
            this.OnPlayerTick(packet);
        }
        return;
    case Message.Type.GiveUserInformation:
        using (TimeWarning.New("GiveUserInformation", 20L))
        {
            this.OnGiveUserInformation(packet);
        }
        return;
    }
    goto IL_3A;
    }
    
    This function does go through all cases of message types complete up to the end...
    Code:
    // Network.Message.Type
    public const Message.Type GroupDestroy = 8;
    ...and ends then with the mentioned Debug Warning, because the above function does NOT handle that message type.

    The message itself and its type is created by the client for any reason and is assigned to this client function:
    Code:
    // Client
    private void OnGroupDestroy(Message msg)
    {
    uint uid = msg.read.GroupID();
    List<BaseNetworkable> list = Pool.GetList<BaseNetworkable>();
    BaseNetworkable.clientEntities.FindInGroup(uid, list);
    for (int i = 0; i < list.Count; i++)
    {
        BaseNetworkable baseNetworkable = list[i];
        if (!(baseNetworkable == null))
        {
            if (!(baseNetworkable.gameObject == null))
            {
                if (!baseNetworkable.ShouldDestroyWithGroup())
                {
                    baseNetworkable.LogEntry(BaseMonoBehaviour.LogEntryType.Network, 1, "skipping OnGroupDestroy - ShouldDestroyWithGroup == false");
                }
                else
                {
                    baseNetworkable.NetworkDestroy(baseNetworkable.ShouldDestroyImmediately());
                }
            }
        }
    }
    Pool.FreeList<BaseNetworkable>(ref list);
    }
    
    In conclusion: FacePunch needs to take a look into the whole thing!
     
  13. Mb oxide developers can add the possibility of use hook for OnNetworkMessage method? Then we can just check packet type and block him if he incorrect.
    Or in oxidemod patch remove debug log in this method.
     
  14. Wulf

    Wulf Community Admin

    You can hide the message in your console if it is bothering you by using the FilterExt plugin. It doesn't seem to be a widespread issue though, but ideally Facepunch should look into it. I don't think it's actually doing any damage other than spamming the message.
     
  15. xD
    Some one send incorrect packet to server and you propose ignore this message, when the server crashes because of it?
    Do you think that if you hide it, the server will not fall?
     
  16. Wulf

    Wulf Community Admin

    The packet is unhandled, so the only affect I see is that your console is being spammed with a message; which would be the only cause for it to "crash" that I can see. If the packet was actually causing an issue other than a log message, I'm pretty sure you would have felt it by now.
     
  17. Do you think that the problem with the disk and load on IO?
     
  18. Wulf

    Wulf Community Admin

    No, the console just can't handle excessive amounts of prints.