Same issue here. Any luck figuring it out?
I see this issue coming up all over the place (I saw a few more but can't seem to find them now):
Very interesting... I've raised the issue with our engineering team.
Does anyone on the thread have an open Support Case on this issue?
I opened one this morning. No response yet.
Request # 17340097701
I had this problem today in a freebsd guest. Switching to bridged networking works around it for me.
I've been experiencing this problem since Fusion 8.1.0. I work with macOS VMs that frequently stall on large HTTP(S) downloads and Git clones over HTTPS. The criteria seem to be, for me:
- Using a NAT-configured virtual NIC
- "Fast enough" downstream bandwidth available (probably at least 5MBps down)
- "Large enough" file that the connection has at least a few seconds to pull data down without the transfer being complete
The numbers aren't identical each time, but it does not take many attempts to trigger the error. I've experienced this both on a large (fast) University network connection and on MacMiniColo-hosted Mac Minis. In all cases these are VMs running OS X 10.11.6, but it would seem from this thread that FreeBSD guests may exhibit the same issue. Numerous others have confirmed the same findings and most people tend to switch to bridged networking to avoid the issue. Unfortunately that's not a possible network configuration in some of the environments I work in.
Here's a video demonstrating how trivial it is to trigger the bug, wherein I attempt to download the Office 2016 installer, which is over 1GB in size:
You can see that around 2:40, I've done 4 downloads of the same ~1GB installer of the 2016 Office for Mac installer, 3 out which have stalled indefinitely.
A workaround I've been using for a while is to use a current VMware Fusion app but drop-in replace the vmnet-natd binary with the version from 8.0.2, or to use this one that's available for download (which was distributed by VMware to resolve the 8.1.x NAT port forwarding issue):
I received a reply to my support request. They were able to reproduce the issue and said that the fix will be included in the next release!
I have a similar issue which I believe to be the same. See this post with detailed reproducibility results as well as an in-depth breakdown of the symptom: macOS 10.12 guest socket timeout with TCP window reduced to 0