Repository navigation
0.24.0: host silently drops packets to a new guest on ~15% of boots (guest-to-host still works) #213
Description
Summary: since upgrading to softnet 0.24.0, about 12–16% of VM boots come up with the host unable to reach the guest. The guest boots, gets its address and keeps sending traffic to the host, but every unicast packet from the host to the guest is silently dropped. SSH from the host sits in SYN_SENT until it times out. With 0.23.0 on the same machine: 0 of 842 boots over three days, and 0 of 34 since downgrading back.
Environment:
- macOS 26.6.2 (25G83), Apple silicon
- tart 2.37.0
- softnet 0.24.0-b869e33 (Homebrew)
- ephemeral CI VMs: clone, boot with
--net-softnet, SSH in, run one job, delete; two concurrent VMs at most
What we observed on three failing boots (5-second sampling, read-only, no root):
- The guest gets its /30 from softnet within about 10 s. The ARP entry and route on the host are correct:
route -n get <guest>resolves to the rightbridge10N, UP. - Guest-to-host traffic keeps arriving: the bridge's and
vmenetN's input packet counters rise 2–5 packets/s for the whole failure. - Host-to-guest traffic never leaves. Pings, TCP SYNs to port 22,
ping -bon the bridge andping -S <gateway>all leave the bridge's andvmenetN's output packet counters unchanged. Meanwhile a healthy sibling VM on the other bridge answers pings in 0.4 ms with its counters moving. - No "no route", no-buffers or NECP counters moved.
- One boot recovered on its own about 90 s in. The rest stayed unreachable for the full 300 s timeout.
- Failures correlate with a new VM's bridge reusing the interface name of one torn down seconds earlier (e.g. a new VM inheriting
bridge102about 2 s after the previous VM on it was destroyed). Some failures also came minutes after the last teardown, so this isn't proven.
Not yet checked: whether pf or Internet Sharing NAT state holds the drop. That needs root (pfctl -s states, tcpdump -ni bridge10N during a live failure); we can add it if useful.
Workaround: downgrading to softnet 0.23.0 (shared vmnet network, macOS DHCP) stopped the failures entirely for us. We also added a boot probe that kills and retries a VM whose port 22 stays silent after its IP appears.
Possibly related: #212, about bootpd rejecting its config while a 0.24 VM runs, and the 0.24.0 networking change #209.
Activity
edi-oai commentedon Oct 9, 2026
Hello Evan 👋
Thank you for reporting this!
Should be fixed by #215.
The ~15% that you've observed also roughly corresponds to a 12.38% chance of:
192.168.0.0/16poolpcshrosbree commentedon Oct 12, 2026
We hit the same symptom on softnet 0.24.0 and read the host's packet filter while a VM was in the failing state, before 0.24.1 was released. In case it is useful, here is the filter-level evidence. It is consistent with the diagnosis behind #215.
Environment: macOS 27.0.1 (26A434), Apple M5 Max, Tart 2.40.1, softnet 0.24.0-b869e33 from Homebrew. The VM was started as
tart run --net-softnet --net-softnet-allow <two /32 addresses outside the VM subnet> --no-graphics ..., so softnet ran with the default--vm-net-type natand--allowset to the same two addresses. One VM was running at the time.The failing boot. The guest got
192.168.243.154on a/30, with gateway192.168.243.153onbridge100. The guest's pings and DNS queries to the gateway showed up intcpdumponbridge100with no reply. The host's connection attempt to the guest's port 22 never appeared onbridge100, and the host socket sat inSYN_SENT. Traffic from the guest to one of the allowed addresses went through NAT normally: an HTTPS request completed, with both directions visible onbridge100. The host never reached the guest over SSH in the hour before our CI job timed out.pfctl -a com.apple.internet-sharing/network_isolation -vv -s rulesduring the failure (excerpt; thelo0rules@2/@3and the IPv6 block rule@5are omitted):network_isolation_table_v4held192.168.243.152/30. So the IPv4 pass rule had lost its/30and named only the network address, while the IPv6 pass rule kept its/64. IPv4 traffic within the/30therefore fell through to@4, whose drop count kept rising while we watched.The failing boot and the next four, on the same host and under the same
InternetSharingprocess, polled about every 5 seconds:@0@4192.168.243.152/30(the failing boot)from 192.168.243.152 to 192.168.243.15210.165.252.68/30from 10.165.252.68/30 to 10.165.252.68/3010.101.0.164/30from 10.101.0.164/30 to 10.101.0.164/3010.183.183.64/30from 10.183.183.64/30 to 10.183.183.64/30172.29.200.92/30from 172.29.200.92/30 to 172.29.200.92/30Written out, the failing subnet
192.168.243.152/30is 18 characters long; the four healthy ones are 15 or 16. That fits your explanation above: a192.168.x.ysubnet with three-digit third and fourth octets.Rate. Between 8 and 12 October, 31 of 264 boot attempts on this host that reached the SSH wait never completed it, about 12%. That count includes retries and excludes a deliberate short-timeout test. It is close to your 12.38% estimate. Most of the 31 were cut off by our 120 s boot timeout and retried on a fresh VM. Up to our last check of the installed version (0.24.0, on 10 October), it was 5 of 80. We read the filter rules for only one of the 31, so the others are not confirmed to be this rule.
No action requested. The rules are owned by macOS's Internet Sharing (
com.apple.internet-sharing), and its log shows it committing filter rules throughpfdwhen it set up the next network, so the dropped prefix looks like a macOS bug. We are considering a Feedback Assistant report. If you have already filed one, an FB number would let us reference it.Note
This comment was prepared with AI assistance (Anthropic Claude, checked by OpenAI Codex) at my request. I reviewed it and the captures before posting.
pcshrosbree commentedon Oct 12, 2026
Filed with Apple as FB25165722, with the two sysdiagnoses taken while the rule was live.