Additional Finding That May Help With MCPE-239705

I would like to share one finding from troubleshooting this issue that may be useful to developers and other affected users.

I was able to reproduce an InitialConnection failure even though the Bedrock Dedicated Server itself appeared to start normally.

The server reached:

Server started.

The UDP game port was open and the Bedrock server process was listening normally.

However, Bedrock/RakNet status requests were returning an empty response, and clients were still unable to complete the connection.

Finding in the Existing World

I inspected the affected world's level.dat and found:

LANBroadcast = 0

At the same time, the dedicated server configuration already contained:

enable-lan-visibility=true

This means the value stored inside the world did not match the server's LAN visibility configuration.

Before testing anything, I stopped the server and created a backup of level.dat.

I then changed only:

LANBroadcast = 0

to:

LANBroadcast = 1

After restarting the same dedicated server with the same world, the behavior changed immediately.

Before the Change

After the Change

No changes were made to the world database, gameplay settings, router configuration, firewall rules, or server port during this comparison.

The only change was the LANBroadcast value inside level.dat.

Why This May Be Relevant

This suggests that enable-lan-visibility=true in server.properties may not be sufficient in every affected world.

An existing world can apparently retain:

LANBroadcast = 0

inside level.dat, and in my test this affected the Bedrock/RakNet response even though the dedicated server reported that it had started successfully.

This may be worth checking in other reports of MCPE-239705, particularly when all of the following are true:

1. Bedrock Dedicated Server reaches Server started.

2. UDP 19132 is listening normally.

3. The client still fails during InitialConnection.

4. Bedrock/RakNet status requests receive no valid response.

5. enable-lan-visibility=true is already configured.

For affected users, it may be useful to inspect the world's level.dat and compare the stored LANBroadcast value.

A backup should always be created before modifying level.dat.

Additional Observation

During troubleshooting I also found that, on a system with more than one IPv4 address, the same Bedrock server could respond correctly through one local address while another address produced an InitialConnection failure.

This may be a separate networking behavior rather than the same root cause, but it may be useful for affected users to test each available server IP independently instead of assuming that all addresses will behave identically just because Bedrock is listening on 0.0.0.0:19132.

Conclusion

I am not claiming this is a universal fix for MCPE-239705.

I am sharing it because the before/after result was reproducible:

LANBroadcast = 0 → Bedrock/RakNet did not respond correctly

LANBroadcast = 1 → Bedrock/RakNet response started working

The most interesting part is that this occurred while:

enable-lan-visibility=true

was already set in server.properties.

Hopefully this provides another data point for investigating why some affected Bedrock Dedicated Servers report Server started while clients still fail during the InitialConnection stage.

## Update – Reproduced Again on 1.26.45 Using Default Port and zlib

I performed another controlled test using the latest Bedrock client and a more default-like Bedrock Dedicated Server network configuration.

The issue is still reproducible.

### Client

| Item | Details |

|---|---|

| Minecraft Bedrock | **1.26.45** |

| Device | **iPhone 12,5** |

| OS | **iOS 26.6.1** |

| Connection | **Wi-Fi** |

### Server Network Configuration Used for This Test

| Setting | Value |

|---|---|

| IPv4 Port | **19132** |

| IPv6 Port | **19133** |

| LAN Visibility | **true** |

| Compression Threshold | **1** |

| Compression Algorithm | **zlib** |

These settings were used specifically to rule out my previous custom port and Snappy compression configuration as possible causes.

### Result

The connection still fails.

The client now reports:

| Field | Value |

|---|---|

| Error Detail | **InitialConnection-13** |

| Transport | **RakNet:2169** |

| Result | **FAILED** |

So the problem is still reproducible even when using:

- the default Bedrock port **19132**

- default-style IPv6 port **19133**

- `enable-lan-visibility=true`

- `compression-algorithm=zlib`

- `compression-threshold=1`

This makes it unlikely that the issue is caused by my previous custom port or Snappy compression settings.

The failure is again occurring during the **InitialConnection** stage.

For comparison, previous tests produced:

| Test | Result |

|---|---|

| Older client + older BDS | **WORKS** |

| 1.26.40 client + older BDS | **InitialConnection-34 / RakNet:2168** |

| 1.26.40 client + newer BDS | **Prerequisites-32** |

| 1.26.45 client + default port/configuration | **InitialConnection-13 / RakNet:2169** |

I am attaching the screenshot showing the full `InitialConnection-13` error details.

This latest test further suggests that the issue is occurring inside the newer Bedrock connection/handshake path rather than being caused by a custom server port or compression configuration.

Update – Issue Still Reproducible on Bedrock 1.26.45.1

I tested the issue again using Minecraft Bedrock 1.26.45.1.

Unfortunately, the connectivity issue is still present.

However, the behavior has changed compared with previous versions.

Current Test

New Behavior in 1.26.45.1

When attempting to join the Bedrock Dedicated Server:

1. The client starts the connection attempt.

2. The connection/loading screen appears normally.

3. After a short period, the connection attempt stops.

4. The game returns directly to the main screen.

5. No error message or Error Detail screen is displayed.

This differs from the behavior observed in previous versions.

Previous Error Behavior

In earlier tests, the failure produced explicit error details:

Important Observation

The underlying connectivity problem therefore still appears to exist in 1.26.45.1, but the client no longer exposes the same diagnostic error information.

Previously, the failure was visible as:

• InitialConnection-34

• Prerequisites-32

In 1.26.45.1, the connection simply terminates and returns to the main screen without displaying an error.

This may indicate that the failure path or error handling has changed, rather than the underlying connectivity issue being resolved.

The issue has already been reproduced across multiple Bedrock client and Bedrock Dedicated Server versions, as documented in my previous comments on this ticket.

Please investigate whether the networking/handshake failure is still occurring internally in 1.26.45.1 and whether the diagnostic error screen is now being suppressed.

I can provide additional testing or logs if required.

Update: Issue Still Reproducible in Bedrock 1.26.40

I tested the issue again after the release of Minecraft Bedrock 1.26.40.

Unfortunately, the connectivity issue is still present.

I performed a controlled comparison using the same Android device, same Wi-Fi connection, same network, and same server environment, changing only the Bedrock Dedicated Server version.

The important finding is that the error stage changes depending on the BDS version.

Environment

Test Results

Test A — Older Client + Older BDS

Result: WORKS

The older Minecraft client can still connect successfully to the older Bedrock Dedicated Server in the same network/server environment.

This is the known working combination and is being used as the baseline for comparison.

Test B — Client 1.26.40 + Older BDS

Result: FAILS

Error details:

When the 1.26.40 client attempts to connect to the older BDS, the connection reaches the InitialConnection stage and fails with:

InitialConnection-34

Test C — Client 1.26.40 + BDS 1.26.40

Result: FAILS

Error details:

When both the client and Bedrock Dedicated Server are updated to 1.26.40, the failure changes to:

Prerequisites-32

Key Finding

The same client device and network produce two different connection failures depending only on the Bedrock Dedicated Server version:

1.26.40 Client + Older BDS → InitialConnection-34

1.26.40 Client + 1.26.40 BDS → Prerequisites-32

Meanwhile:

Older Client + Older BDS → Works normally

This suggests that the failure is occurring at different stages of the Bedrock connection/handshake process depending on the server version.

Previous Testing

This issue has remained reproducible across multiple Bedrock releases.

Previous troubleshooting has already included:

• Fresh server/world testing

• Existing world testing

• Windows BDS

• Ubuntu BDS

• Default UDP port 19132

• Alternative ports

• Firewall verification

• Port forwarding verification

• enable-lan-visibility=true

• transport=raknet

These changes did not resolve the issue.

Current Status

The issue is therefore still reproducible with Minecraft Bedrock 1.26.40.

The most important comparison is:

I am attaching screenshots showing both error details.

The difference between InitialConnection-34 and Prerequisites-32 may help identify exactly where the newer Bedrock networking/handshake process is failing.

Please investigate whether this is a regression or compatibility issue introduced in the newer Bedrock networking stack / Dedicated Server connection process.

I would like to provide additional reproducible test results, as this issue is still affecting my environment even after updating to 1.26.33.1.

Environment

• Bedrock Dedicated Server (Official)

• Ubuntu Server (also reproduced on Windows)

• Local family server (no proxies, no Docker, no VPN)

• Clean installation

• Fresh world also tested

• Default port (19132) and custom ports tested

• LAN Visibility tested both enabled and disabled

• Allow List tested enabled and disabled

• Online Mode tested enabled and disabled

Test Matrix

This means that introducing either the new client OR the new dedicated server is sufficient to reproduce the failure.

Platforms tested

Clients tested:

• Android

• iPhone (iOS)

Servers tested:

• Ubuntu

• Windows

The behavior is identical on both operating systems.

Error Details

The new diagnostic screen shows different internal error codes depending on the client:

Android:

Prerequisites-32

iPhone:

InitialConnection-13

Older client versions connect successfully to older servers without any issues.

Additional observations

• Fresh world does not solve the issue.

• Existing world does not solve the issue.

• Network configuration has been verified.

• Firewall has been verified.

• Same hardware, same router and same environment work perfectly with version 1.26.23.

• The problem started with the 1.26.30 series and is still reproducible on 1.26.33.1.

This strongly suggests a regression in the Bedrock Dedicated Server connection or handshake process rather than a configuration issue.

Hopefully these reproducible results help identify the remaining cases that were not resolved by previous fixes.

Thank you.