Open wallpunch opened 2 months ago
Hi @wallpunch, thanks for reporting. This seems to be another case of https://github.com/canonical/multipass/issues/3038. Unfortunately, we don't have a solution for this yet. But stay tuned to #3038 for news. Thanks!
Closing of duplicate of #3038.
Reopening because we are not 100% sure it's the same issue as #3038.
Describe the bug On a macOS host, TCP connections bound to an instance's bridged network interface hang after about 50kb data are received.
To Reproduce
multipass set local.bridged-network=en0
multipass launch -n test --bridged
multipass exec test -- curl https://canonical.com -o /dev/null --interface enp0s2
(Sometimes need to repeat Step 3 a few times before it hangs. I don't think it's a curl bug as I've seen the same issue using netcat and even sockets directly.)Expected behavior All TCP data from the server should be received. (The curl request should complete.)
Logs bug.log
Additional info
multipass version
multipass 1.13.1+mac multipassd 1.13.1+macmultipass info
Name: test State: Running Snapshots: 0 IPv4: 192.168.64.65 192.168.69.244 Release: Ubuntu 22.04.4 LTS Image hash: 40ea1181447b (Ubuntu 22.04 LTS) CPU(s): 1 Load: 0.27 0.10 0.03 Disk usage: 1.6GiB out of 4.8GiB Memory usage: 147.7MiB out of 962.3MiB Mounts: --multipass get local.driver
qemuAdditional context The bug does not always occur. It seems more likely to occur when the incoming data arrives very rapidly. It only occurs when more than approximately 50kb are transmitted by the server.
The bug does not occur if the bridged interface is not explicitly bound to (i.e.
curl 'https://canonical.com' -o /dev/null
never hangs).