[BDS-17307] Unable to connect to VM-hosted BDS on same machine Created: 15/Jul/22 Updated: 04/Jan/24 Resolved: 04/Jan/24 |
|
| Status: | Resolved |
| Project: | Bedrock Dedicated Server |
| Affects Version/s: | 1.19.10, 1.19.11 Hotfix, 1.19.20, 1.19.31 Hotfix |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | NotoriousPyro | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 4 |
| Labels: | None | ||
| Environment: |
VM Host:
|
||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Confirmation Status: | Unconfirmed | ||||||||||||||||||||
| ADO: | 891851 | ||||||||||||||||||||
| Description |
|
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.
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. |
| Comments |
| Comment by [Mod] Greymagic27 [ 04/Jan/24 ] |
|
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 |
| Comment by willman42 [ 30/Nov/22 ] |
|
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? |
| Comment by Kal326 [ 27/Nov/22 ] |
|
I 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
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
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 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.
|
| Comment by Valiante [ 21/Sep/22 ] |
|
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 off |
| Comment by Thomas Suominen [ 16/Sep/22 ] |
|
Finally some progress, tx off fixed this issue for me as well! |
| Comment by dogwhisper [ 15/Sep/22 ] |
|
Just to clarify, in my case, its not on the same system that I'm playing on. It's a separate dedicated Hyper-V server running multiple VMs. Linux BDS just happens to be one of them. Just as @NotoriousPyro stated, its fairly common. Good find on disabling checksum. Wonder how far it scales before run into performance issues. Sounds like a possible Linux driver compatibility issue? MS has Linux integration with RHEL and CentOS. Anyone know if this issues also happens on CentOS? https://www.serverwatch.com/guides/installing-and-activating-hyper-v-linux-integration-services/ |
| Comment by NotoriousPyro [ 15/Sep/22 ] |
Because that's an entirely valid and popular configuration for experienced administrators. It isolates resources to the VM, there are many, many reasons why someone would do this. |
| Comment by Rayth [ 15/Sep/22 ] |
|
I'm curious,
Why are you running the server on a VM on the Same PC you're attempting to play with??? Why run it on a virtual linux machine at all rather than just using the Windows BDS Software? |
| Comment by Jack Naisbett [ 11/Sep/22 ] |
|
sudo ethtool -K eth0 tx off
worked for me too, thanks for posting this! |
| Comment by mash883333 [ 11/Sep/22 ] |
|
Some helpful soul posted on another forum $ sudo ethtool -K eth0 tx off |
| Comment by dogwhisper [ 23/Aug/22 ] |
|
Just tried using the most recent 1.19.21 build and still cannot connect to other servers running through hyper-v. As a workaround, I've been able to get this to work with Oracle VirtualBox. For the record, VirtualBox is running on the same box as the Hyper-V instances. Most recent MS patches are installed. |
| Comment by dogwhisper [ 18/Aug/22 ] |
|
Noticed that the other threads I mentioned are now linked back to this one. Adding my notes from those here so they don't get lost: Did some more digging into the RAKNET network traffic based on this: A traffic comparison between with and without the KB5015807 shows that the MC Client sends an ACK (0xc0), it passes through the Hyper-V HOST/Server, the Ubuntu server sees the ACK and responds with it's own ACK, but that ACK is not passed through the Hyper-V Host back the the client. Just a theory but I'm wondering if the Hyper-V CVE fixes from July may have unintentionally be impacting the ability for RAKNET to send the ACK back from the VM Guest. There are two hyper-v changes in the July KB release notes that might be related: |
| Comment by dogwhisper [ 17/Aug/22 ] |
|
Having same problem. Sounds like there are a few other threads on this issue. |
| Comment by NotoriousPyro [ 17/Aug/22 ] |
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. |
| Comment by Omar Berrow [ 16/Aug/22 ] |
|
a vm isn't connected directly to your internet so that is your problem |
| Comment by NotoriousPyro [ 16/Jul/22 ] |
|
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... |
| Comment by rob_r1234r5678 [ 16/Jul/22 ] |
|
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. |