mojira.dev

dogwhisper

Assigned

No issues.

Reported

No issues.

Comments

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/

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.

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: BDS-17401

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:

CVE-2022-30223

CVE-2022-22042

Did some more digging into the RAKNET network traffic based on this: BDS-17401

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.

I did a RAKNET comparison between with and without the KB5015807.  What I am seeing is that the Client sends an ACK (0xc0), it passes through the Hyper-V HOST/Server, the Ubuntu server sees it and responds with it's own ACK, but that ACK is not passed through the Hyper-V Host back the the client.

The malformed packet (0x9) from the MC client to the Bedrock server shows up with and without the KB. 

Did some more digging into the RAKNET network traffic based on this: BDS-17401

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.

Same issue here.  I have to remove most recent security patches on windows host to get it to work. See comments here.  These all looks like similar issues.

BDS-17313

BDS-17499

BDS-17401

BDS-17307

Having same problem. Sounds like there are a few other threads on this issue.

BDS-17313

BDS-17401

Same issue here.  I have to remove most recent security patches on windows host to get it to work. See comments here.  These all looks like similar issues.

BDS-17313

https://bugs.mojang.com/browse/BDS-17499

BDS-17401

https://bugs.mojang.com/browse/BDS-17307

Also tried installing it on a new ubuntu 22.04 with same results.

Appears to still be an issue with the Microsoft August updates.  Had to remove them then re-remove the July update.  I can see this becoming more and more problematic.  Any ideas/suggestions?

 

Also running 1.19.11

I ran into a similar issue on Windows 10 running an Ubuntu Bedrock server through Hyper-V.  Have to remove the comparable patch kb5015807 on the HOST if I want it to work.

There are two hyper-v changes in the KB release notes that might be related:

CVE-2022-30223

CVE-2022-22042