mojira.dev
BDS-23065

Server sends cut off UnconnectedPong packets if LANBroadcast=0b in level.dat

In the latest version, if a world is loaded on a dedicated server with its LANBroadcast tag set to 0, the server will send broken pong packets in response to pings.

How to reproduce

  • Download the dedicated server files

  • Start the server to create the initial world and stop it again

  • Change LANBroadcast to 0 in the level.dat using an NBT editor, or use the attached lavel.dat file.

  • Start the server again

  • Ping the server with a ping utility of your choice (e.g. https://www.npmjs.com/package/craftping)

  • See an error message that the response is too short

Issue

Pong packets normally consist of an ID/timestamp echoed from the ping request, a server id, 16 bytes of magic, the length of the body, and the body, which is a string with status information about the server. In the case where LANBroadcast ist 0, it cuts off after the magic.

Correct response:

00000000  1c f5 59 03 f9 c4 95 a9  8e 87 b0 a4 af 9c 2d b6  |..Y...........-.|
00000010  d3 00 ff ff 00 fe fe fe  fe fd fd fd fd 12 34 56  |..............4V|
00000020  78 00 67 4d 43 50 45 3b  44 65 64 69 63 61 74 65  |x.gMCPE;Dedicate|
00000030  64 20 53 65 72 76 65 72  3b 31 30 30 31 3b 31 2e  |d Server;1001;1.|
00000040  32 36 2e 33 30 3b 30 3b  31 30 3b 39 37 37 37 34  |26.30;0;10;97774|
00000050  39 35 38 36 35 31 36 37  38 32 30 34 39 39 3b 42  |95865167820499;B|
00000060  65 64 72 6f 63 6b 20 6c  65 76 65 6c 3b 53 75 72  |edrock level;Sur|
00000070  76 69 76 61 6c 3b 31 3b  33 36 31 32 32 3b 31 39  |vival;1;36122;19|
00000080  31 33 33 3b 30 3b 31 3b  30 3b                    |133;0;1;0;|
0000008a

Incorrect response:

00000000  1c 04 c4 1a 83 e8 48 93  e4 be 09 f8 97 7d b4 fe  |......H......}..|
00000010  ed 00 ff ff 00 fe fe fe  fe fd fd fd fd 12 34 56  |..............4V|
00000020  78                                                |x|
00000021

How exactly worlds with LANBroadcast=0 come to be I don’t know. But users have repeatedly uploaded worlds like this to our platform and reported issues as a result of the bug, so I assume some client/editor option causes the tag to be set to 0. Dedicated servers do not have an option to change/overwrite this back to the correct value. I would say this is a bug, since it makes it impossible to use those worlds correctly on a server for normal users who don’t have access to this information and an NBT editor.

I also don’t see why a field called LANBroadcast would be related to dedicated servers not responding to pings correctly. This is not about the server broadcasting anything, it’s just about responding to network requests.

Environment

Bedrock Dedicated server for Linux

Attachments

Comments 4

Thank you for helping us improve Minecraft! We saved your files:

[media]

I can confirm this also still happens on BDS 1.26.32.2

Thought my world was corrupted somehow, then I found this issue.

The server seemingly runs normally, but the game can’t connect or even ping until the NBT tag is fixed.

This issue has been reviewed by our team.

Please add new, relevant information if it helps us understand or reproduce the issue. To show that you’re affected, use the vote feature rather than commenting.

If a fix is implemented, it will be listed in our official changelogs.

For major outages or urgent assistance, visit the Minecraft Help Center.

I think this is the same issue I’ve seen. As of a June 2026 release of BDS I could not get any clients to connect to my local server, it having been successful in May.
Eventually by trial and error I tracked it down to this LANBroadcast settings being 0 in my level.dat. I used a tool to modify it to 1 and suddenly clients could connect again.

No changes to server.properties allowed me to resolve this.

It is probable that this world was began life (a few years back) as a single player game (or has been used as a single player game at some point) which may explain it, but either way was a nightmare to track down as there is no helpful information logged that I could see.

KurtThiemann

(Unassigned)

Community Consensus

Retrieved