Russell Martin

Additional identity/trust detail:
The BDS installation has a persistent saved NetherNet server identity key, which is retained across BDS restarts. The same identity key was present throughout the failed LAN joins, the successful manual Windows join, and the subsequently successful Windows and Xbox LAN joins. I have not deleted or regenerated the identity key during testing.

Additional reproducible information for BDS 1.26.52.3 on Ubuntu Linux

I can reproduce a related NetherNet connection problem on Bedrock Dedicated Server 1.26.52.3.

Environment

• Bedrock Dedicated Server: 1.26.52.3, Build ID 51798919

• Server OS: supported Ubuntu Linux

• Transport: nethernet

• Server port: 19132

• LAN visibility: enabled

• server-udp-ports: not configured, using the stock default

• Server and clients on the same local network

• Clients tested: Minecraft for Windows and Xbox

• Clean, stock-based server.properties, with only ordinary gameplay customisations

Observed behaviour after each BDS restart

1. The server starts successfully, listens on [::]:19132, and reports successful sign-in to the signalling service.

2. The server is visible through LAN discovery.

3. Joining through the LAN-visible entry initially fails.

4. Joining once from Minecraft for Windows through a manually saved server address using the server’s local IPv4 address and port 19132 succeeds.

5. After that successful manual Windows connection, the Windows LAN-visible entry succeeds.

6. The Xbox LAN-visible entry then also succeeds.

7. Restarting BDS resets the behaviour, and the manual Windows connection must be performed again.

Expected behaviour

A LAN-visible NetherNet server should be joinable directly after BDS starts, without requiring a successful manual Windows connection first.

Workaround

After each BDS restart, connect once from Minecraft for Windows using a manually saved local server address on port 19132. LAN-visible joins then work from Windows and Xbox until the next BDS restart.