Game hangs randomly with WRN NET: LiteNetLib: IP requested for unknown client

[Thomas Bishop]

Version

2.5

Platform

Windows

Server has no mods except TFP mods that come with it.
Game will hang randomly with these messages repeated.
Log is attached.

2026-01-05T15:04:26 42998.969 INF Started thread NCS_Reader_7_14
2026-01-05T15:04:26 42998.969 INF [NET] PlayerConnected EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='68'
2026-01-05T15:04:26 42998.969 INF Started thread NCS_Writer_7_14
2026-01-05T15:04:26 42999.048 INF NPPL.Read
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=10847, PltfmId='Steam_76561198860391117', CrossId='EOS_0002522ee4094e1ab0f50f1952098293', OwnerID='Steam_76561198860391117', PlayerName='cali19772004', ClientNumber='29'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=11393, PltfmId='Steam_76561198041098869', CrossId='EOS_0002bdd3b7e04717b524993b79b05a0b', OwnerID='Steam_76561198041098869', PlayerName='sleibner', ClientNumber='42'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=1539, PltfmId='Steam_76561199570735958', CrossId='EOS_000215842a3243bd862d032806403edf', OwnerID='Steam_76561199570735958', PlayerName='Moody', ClientNumber='46'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=173, PltfmId='Steam_76561198126562484', CrossId='EOS_00027ca8d6ae430ca614c452bee1cac3', OwnerID='Steam_76561198126562484', PlayerName='caliman101476', ClientNumber='47'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=12497, PltfmId='Steam_76561198975844378', CrossId='EOS_0002368a84ec4ebda6c4e40dc4465801', OwnerID='Steam_76561198975844378', PlayerName='ItzBryanDuhhh', ClientNumber='48'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='49'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='51'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='54'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='55'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='56'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='57'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='61'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='62'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='63'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='65'
2026-01-05T15:04:31 43004.033 WRN NET: LiteNetLib: IP requested for unknown client EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='66'
2026-01-05T15:04:31 43004.064 INF NET: LiteNetLib: Connect from: 47.144.120.185:62617 / 6
2026-01-05T15:04:31 43004.065 INF Started thread NCS_Reader_6_02
2026-01-05T15:04:31 43004.065 INF Started thread NCS_Writer_6_02
2026-01-05T15:04:31 43004.065 INF Started thread NCS_Reader_6_12
2026-01-05T15:04:31 43004.066 INF [NET] PlayerConnected EntityID=-1, PltfmId='Local_<none>', CrossId='<unknown/none>', OwnerID='<unknown/none>', PlayerName='', ClientNumber='69'
2026-01-05T15:04:31 43004.066 INF Started thread NCS_Writer_6_12
2026-01-05T15:04:31 43004.113 INF NPPL.Read

 

[arramus]

Based on the log entry, this looks like a Host Havoc server.
The issue starts to appear after the server had been up for about 12 hours. The error suggests it is a random hang, but is it more likely after an extended play through of 8 hours + without a server restart?
How is RAM holding up when these messages start to appear? A server without any mods generally boots up and stabilises between 3.5 - 4GB. However, that will rise over time. If the server package is 8GB, as soon as things climb to about 6-6.5GB there can be spikes which push things a little too much and this type of instability can occur. If the package is 12GB, then that is not typically a factor at the time frame the issues appear. Even so, 7 Days servers benefit from restarts every 6-8 hours to refresh RAM and other processes.
Consider restarting every 8 hours or so just to see if it stabilises things.

A precursor to the LiteNetLib connection issues was an EOS break down just slightly above the log entries shared.
2026-01-05T14:57:32 42584.693 ERR [EOS-ACS] Failed decrypting stream from EOS_0002bdd3b7e04717b524993b79b05a0b: AntiCheatProtectMessageValidationFailed
It could also be that Epic Online Services was having a moment.
Even so, restarting a little more frequently helps to refresh and reestablish handshakes.

 

[Thomas Bishop]

Thanks the quick response! I tried everything I knew before reporting this.

Based on the log entry, this looks like a Host Havoc server.

That is correct.

The issue starts to appear after the server had been up for about 12 hours. The error suggests it is a random hang, but is it more likely after an extended play through of 8 hours + without a server restart?

The issue happened again less than 15 minutes after the restart shown in the log. I have a very short log for that.
https://justpaste.it/jo60z

How is RAM holding up when these messages start to appear? A server without any mods generally boots up and stabilises between 3.5 - 4GB. However, that will rise over time. If the server package is 8GB, as soon as things climb to about 6-6.5GB there can be spikes which push things a little too much and this type of instability can occur. If the package is 12GB, then that is not typically a factor at the time frame the issues appear. Even so, 7 Days servers benefit from restarts every 6-8 hours to refresh RAM and other processes.
Consider restarting every 8 hours or so just to see if it stabilises things.

I have 20GB RAM, more than the max 16GB Host Havoc allotment (I had to beg) because it kept running out of RAM, even on a 4-hour restart schedule. RAM used was 9416.8MB at the time of the hang.

A precursor to the LiteNetLib connection issues was an EOS break down just slightly above the log entries shared.
2026-01-05T14:57:32 42584.693 ERR [EOS-ACS] Failed decrypting stream from EOS_0002bdd3b7e04717b524993b79b05a0b: AntiCheatProtectMessageValidationFailed
It could also be that Epic Online Services was having a moment.

Looking at the logs again, this message seems to be the first ERR before it starts to hang in most or all of the logs (it's a different client each time):
2026-01-05T14:57:31 42583.974 ERR [NET] Client logged in but sent unencrypted message, dropping! EntityID=11393, PltfmId='Steam_76561198041098869', CrossId='EOS_0002bdd3b7e04717b524993b79b05a0b', OwnerID='Steam_76561198041098869', PlayerName='sleibner', ClientNumber='42'
Could this be the root cause of the connection issue? I don't know what to do about it.

Even so, restarting a little more frequently helps to refresh and reestablish handshakes.

I restarted at 4-hour intervals before starting fresh with no mods. I had the same errors at that time, that's why I am running without mods, to debug the issue. I will setup a 4 hour restart schedule and monitor the situation.

I also ran steam file validation and the errors still happened after that.

This wasn't an issue for me until Version 2.5 but I don't see other people complaining about it.

I'll take your advice. Thanks for your help.

 

[arramus]

Running out of 16GB RAM on a 4 hour restart cycle suggests issues beyond your control, unless it was one incredibly resource heavy mix up of mods. I visit a number of community Discord quite regularly through Mod Launcher support activities and this specific issue is not being discussed at all for V2.5, so far. Spartan-85 community and Jean's Gaming community use the same Server Host for comparison and have been silent about this. The only complaint is heavy warping/banding when in city areas and that has been posted in bugs already for SP and dedis for all platforms. There's always routing/hardware considerations if everything else gets rules out when attempting to run things on a frequent restart cycle with such low server mod demand and high redundancy elsewhere. You're collecting plenty of data for review and regardless of where this post ends up, it's being presented as an issue.

 

[Thomas Bishop]

I just wanted to share this Player/Memory/CPU graph from my server because it's interesting. The vertical blue line is when I wiped it and removed all mods.
You can see the memory usage is much lower with roughly the same number of players and no mods.

 

[Thomas Bishop]

Possible solution?

Server has been hanging with this error once or twice every day until I turned off chunk reset:

ERR [NET] Client logged in but sent unencrypted message, dropping!

I've had problems in the past with chunk reset. Server has been up a day and a half with no errors.

I changed this:

<property name="MaxChunkAge"                    value="7"/>

To this:

<property name="MaxChunkAge"                    value="-1"/>

 

[WretchedDollie]

Hello Thomas,

We are investigating some reported freeze issues. If this continues to occur, please post the logs for us.

Thanks,
Dollie

 

[Thomas Bishop]

Hello Thomas,

We are investigating some reported freeze issues. If this continues to occur, please post the logs for us.

Thanks,
Dollie

There have been no freezes since I turned off chunk reset. I'm not seeing the above errors in the log now either. When a player gets an error and drops it doesn't crash the server.

We're running the ProjectZ mod and things are working well.

I'd like to turn on ChunkReset but every time I do I have problems. Coincidence or not, I don't know.

If there is anything I can do for you please ask.

 

[WretchedDollie]

Hi Thomas,

Thank you for letting me know. I'll still look into this further to see if there is any relationship between the freezes and chunk resets.

Thanks,
Dollie

 

[kotfoxtrot]

Random server hang — root cause is an AB/BA deadlock between MultiBlockManager and RegionFileManager​

Follow-up to this thread. Thomas's observation that disabling chunk reset stops the freezes is correct — I can confirm it from a thread dump captured on a server already in the hung state. The cause is a classic AB/BA deadlock on two locks inside the engine itself; chunk reset (MaxChunkAge > 0) is the trigger that opens the deadlock window. No mods are involved in the deadlocked stacks.

Server info​

• Version: V 2.6 (b14), Build LinuxServer 64 Bit
• OS: Ubuntu 24.04, Linux 6.8
• Save age: ~23 days since wipe
• MaxChunkAge: 7 at time of hang (default behaviour: chunk reset enabled)

How I captured this​

Server was already hung (game thread silent, LiteNetLib still accepting connections, log filling with IP requested for unknown client EntityID=-1 warnings). I sent kill -SIGQUIT to the Mono process to dump all managed thread stacks into the log.

Root cause: AB/BA deadlock​

5 threads in the dump are blocked on __icall_wrapper_mono_monitor_enter_v4_internal (waiting on a managed lock). Two of them form the deadlock; the other three are bystanders piling up behind the first two.

Thread A — GenerateChunks​

Holds MultiBlockManager lock, waiting for RegionFileManager lock:

"GenerateChunks"
  at __icall_wrapper_mono_monitor_enter_v4_internal              <-- BLOCKED
  at RegionFileManager.MergeOrCreateChunkGroup
  at RegionFileManager.AddGroupedChunks
  at MultiBlockManager.TryRegisterCrossChunkMultiBlock
  at MultiBlockManager.UpdateTrackedBlockData                    <-- HOLDS MBM LOCK
  at Chunk.SetBlock
  at WorldDecoratorBlocksFromBiome.decorateSingleBlockTryPlaceDeco
  at WorldDecoratorBlocksFromBiome.decorateSingleBlock
  at WorldDecoratorBlocksFromBiome.decorateSingleBlocks
  at WorldDecoratorBlocksFromBiome.DecorateChunkOverlapping
  at ChunkProviderGenerateWorld.decorate
  at ChunkProviderGenerateWorld.tryToDecorate
  at ChunkProviderGenerateWorld.updateDecorationsWherePossible
  at ChunkProviderGenerateWorld.GenerateSingleChunk
  at ChunkProviderGenerateWorld.GenerateChunksThread

Thread B — SaveChunks​

Holds RegionFileManager lock (entered while running CullExpiredChunks), waiting for MultiBlockManager lock:

"SaveChunks ..."
  at __icall_wrapper_mono_monitor_enter_v4_internal              <-- BLOCKED
  at MultiBlockManager.CullChunklessData
  at RegionFileManager.RemoveChunks                              <-- HOLDS RFM LOCK
  at RegionFileManager.CullExpiredChunks
  at RegionFileManager.DoSaveChunks
  at RegionFileManager.thread_SaveChunks

Bystanders (also blocked on MultiBlockManager)​

• Main game thread: GameManager.Update → World.OnUpdateTick → MultiBlockManager.UpdateAlignment (this is why the server stops ticking and players can no longer log in)
• ChunkCalc: ChunkManager.task_Lighting → MultiBlockManager.OnChunkInitialized
• ChunkRegeneration: ChunkManager.RegenerateNextChunk → MultiBlockManager.OnChunkRegeneratedOrDisplayed

Lock-ordering analysis​

Two distinct call paths take the locks in opposite order:

Path	First lock	Second lock
Chunk.SetBlock → MultiBlockManager.UpdateTrackedBlockData → RegionFileManager.MergeOrCreateChunkGroup (called from GenerateChunks during world decoration)	MBM	RFM
RegionFileManager.DoSaveChunks → CullExpiredChunks → RemoveChunks → MultiBlockManager.CullChunklessData (called from SaveChunks)	RFM	MBM

When both paths run concurrently, the deadlock is reachable. The window is narrow but inevitable on a long-running server: chunk generation happens whenever players move into ungenerated terrain, and CullExpiredChunks runs continuously while MaxChunkAge > 0.

Trigger correlation​

This server ran without any hangs while MaxChunkAge was disabled (-1). Hangs started immediately after I set MaxChunkAge="7" to enable chunk reset, and stop again when reverted to -1. This is the same pattern Thomas reported earlier in this thread, and the dump explains it: MaxChunkAge="-1" makes CullExpiredChunks a no-op, which removes one of the two paths and prevents the deadlock from ever being reachable.
On our setup the hang occurs reliably within 2–8 hours of uptime when MaxChunkAge="7" and at least one player is generating new terrain on a save with chunks past the age threshold.

Suggested fix directions​

1. Reorder lock acquisition so MBM and RFM are always taken in the same order on both paths. The SaveChunks path looks easier to change — CullChunklessData could be invoked outside the RFM lock, with the chunks-to-cull list snapshotted under the lock first.
2. Use Monitor.TryEnter with timeout in one of the inner acquisitions and back off / retry on contention.
3. Replace one of the locks with a concurrent collection so the inner operation does not need to take the lock at all.

Happy to provide the full thread dump (~120 threads) if it helps. The five stacks above are the entire causal chain — every other thread in the dump is a network worker on a WaitHandle, an idle thread-pool worker, or a mod thread sleeping in Thread.Sleep. None touch MultiBlockManager or RegionFileManager.

 

[Thomas Bishop]

Wow! Thanks for the great detective work and thanks for explaining it in such great detail. A fascinating read and very well written up. Chunk generation is bumping heads with chunk reset.