As a player who originally started playing Minecraft since the very early days of Java alpha up and stopped playing until not long after Notch left Mojang, I have returned recently after having played split-screen on my daughter's switch with her. While fun, the switch does struggle with two players and also hosting a server.
Wanting to take it to the next level and getting a proper server and also inviting a good friend of mine, I set up a virtual machine on Hyper-V and installed Ubuntu 22 and the OpenSSL deps, completely fresh system and it doesn't work. Nothing I could do, even forwarding the ports to the public internet (bear in mind this is the same PC on the same network, its just a VM) would fix it. I even tried the instructions in the manual to change loopback settings, nada...
Here are the reproduction steps Mojang.
Set router to 192.168.0.1/24... e.g. 192.168.0.1 and subnet 255.255.255.0
Set Host OS to 192.168.0.10/24
Install Ubuntu on Hyper-V in bridged networking mode.
Set Ubuntu VM to static as 192.168.0.50/24.
Install LibSSL 1.1.1:
sudo curl -o libssl.deb -k -L http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/libssl1.1_1.1.1l-1ubuntu1.6_amd64.deb sudo dpkg -i libssl.deb
Set whitelist for the desired players and enable it.
Run the server
Try to add the server to 'Servers'. Can see the server online and responding.
Try to connect to the server. Times out after a few minutes.
minecraft@minecraft:~/server$ LD_LIBRARY_PATH=. ./bedrock_server
NO LOG FILE! - setting up server logging...
[2022-07-14 15:33:18:082 INFO] Starting Server
[2022-07-14 15:33:18:082 INFO] Version 1.19.10.03
[2022-07-14 15:33:18:082 INFO] Session ID 0074ddff-17a0-4b9b-bc43-7e0f67f3c60f
[2022-07-14 15:33:18:082 INFO] Level Name: Bedrock level
[2022-07-14 15:33:18:084 INFO] Game mode: 0 Survival
[2022-07-14 15:33:18:084 INFO] Difficulty: 1 EASY
[2022-07-14 15:33:18:109 INFO] opening worlds/Bedrock level/db
[2022-07-14 15:33:18:461 INFO] IPv4 supported, port: 19132
[2022-07-14 15:33:18:461 INFO] IPv6 supported, port: 19133
[2022-07-14 15:33:18:627 INFO] Server started.
[2022-07-14 15:33:18:655 INFO] IPv4 supported, port: 36352
[2022-07-14 15:33:18:655 INFO] IPv6 supported, port: 35462
[2022-07-14 15:33:18:677 INFO] ================ TELEMETRY MESSAGE ===================
[2022-07-14 15:33:18:677 INFO] Server Telemetry is currently not enabled.
[2022-07-14 15:33:18:677 INFO] Enabling this telemetry helps us improve the game.
[2022-07-14 15:33:18:677 INFO]
[2022-07-14 15:33:18:677 INFO] To enable this feature, add the line 'emit-server-telemetry=true'
[2022-07-14 15:33:18:677 INFO] to the server.properties file in the handheld/src-server directory
[2022-07-14 15:33:18:677 INFO] ======================================================In my old Java days of setting this up would have been a similar process and would have worked flawlessly. There is nothing to suggest what the problem is and the server appears online but remains not connectible.
Linked issues
is duplicated by 4
Attachments
Comments 17
I also recently discovered that it requires a 3rd party workaround to fool the Minecraft Switch client into connecting to a Bedrock Dedicated Server. Honestly I am amazed by the poor design of this system and the blatant money-grab towards using realms...
a vm isn't connected directly to your internet so that is your problem
You are wrong, because bridged network adapters exist, but the problem is actually Microsoft do not allow Switch clients to connect to BDS and a VM hosted using a bridge network adapter does not allow Windows 10 to connect to it. THAT is the problem. Please educate yourself before you post something unhelpful.
Oh what horrible timing. I rebuilt my Hyper-V server and re-imported all my VMs, including a Bedrock Server I hadn't used for a couple of months. Fired it up to check it was working ok, but couldn't connect (the exact issue described in this ticket). Spent days on and off trying to figure out what I'd cocked up during the re-import, only to discover this bug completely unrelated to what I'd done - just poor timing.
Indeed, sudo ethtool -K eth0 tx off worked a treat for me too.
Edit: It looks like you need to do this after each fresh boot of the VM. Added the following line to root cron (sudo crontab -e) which seemed to do the trick:
@reboot sudo ethtool -K eth0 tx offI have confirmed what Valiante commented as resolving my issues.
"Indeed, sudo ethtool -K eth0 tx off worked a treat for me too."
Running that command results in the following
Actual changes:
tx-checksumming: off
tx-checksum-ipv4: off
tx-checksum-ipv6: off
tcp-segmentation-offload: off
tx-tcp-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]
Edit:
I was able to use the regular non legacy network adapter and not have to keep doing the ethtool script as well.
Adding the following to my netplan yaml file fixed the issue the same as using the ethtool command
transmit-checksum-offload: off
tcp-segmentation-offload: off
tcp6-segmentation-offload: off
The other option is to run a Legacy Network Adapter on Hyper-V hosts which is not ideal either.
My config:
Host: Windows Server Core 2019 Hyper-V role
BDS: v1.19.41
Guest VM: Ubuntu 20.04 LTS
Host Network: Intel X710
Running either Legacy Network Adapter or using 'sudo ethtool K eth0 tx off' on a regular Hyper-V network adapter allows a remote Windows Client connect successfully. On the same VM Host a Windows guest VM running the same Windows BDS version has worked previously as well.
I have actually had this problem all the way back into v1.18. Same VM that was working migrated from vSphere 6.7 to a Hyper-V host no longer works without the above listed changes.
I experienced this last week on v1.19.40.2. Documentation says this affects "new" players, so maybe players who had already joined the server before aren't affected by the changing of the default permission?
See this comment on how to resolve the issue: https://bugs.mojang.com/browse/BDS-17307?focusedId=1201094&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-1201094
Similar issue has occurred on BDS on VM running Ubuntu 22.04LTS, error only started 15 Jul 2022, following client desktops (Win 11) updated with July windows updates.
Connections to online multiplayer services are still working, issue only affects local network hosted BDS.
Update 12:22 - Rolled back Microsoft Update KB5015814 (Security Update) and connection to the BDS server now works. Not an ideal fix for my issue, as security updates are important.