Shared Network drops DHCP after sleep; prl_naptd not running

Parallels 26.1.1 (Apple silicon) -- Shared Network drops DHCP after sleep; prl_naptd not running while bridge100remains

Host(s):

• MacBook Pro M3 Max (Wi-Fi only), macOS 26.0.1 "Tahoe"
• MacBook Pro M4 Max (Ethernet + Wi-Fi), macOS 26.0.1 "Tahoe"

Parallels Desktop: 26.1.1 (latest as of Oct 2025)
Guest: Windows 11 (Apple silicon build)
Parallels Tools: up to date
Network mode: Shared Network (Recommended)
VPN: none
IPv6: disabled on LAN/router

Summary

On my M3 Max host using Shared Network, the Windows VM loses network about once per day (often after lid-close sleep). Inside Windows, the network troubleshooter reports "No DHCP server was found." IPConfig shows a link-local 169.254.x.x with no gateway. Restarting the VM or "Restore Defaults" in Parallels Network settings fixes it immediately. The same VM on an M4 Max host (Ethernet present) has been stable, never losing the network.

This indicates a host-side Shared-Network/DHCP service failure rather than a guest issue.

Repro steps (reliable on M3 Max Wi-Fi host)

1. Set VM to Shared Network (Recommended).
2. Close MacBook lid for several hours/day or two (host sleeps).
3. Open lid; return to VM desktop.
4. VM has no network; Windows 11 shows 169.254.x.x and No DHCP server.

Expected: VM regains its 10.211.55.x address within a few seconds after wake.
Actual: VM self-assigns 169.254.x.x and stays offline until host service is restarted.

What I observed when failure occurs

In Windows (guest):

• ipconfig → IPv4 Address 169.254.x.x, no gateway, mask 255.255.0.0
• Windows Network Troubleshooter → No DHCP server was found.

On macOS (host):

• Parallels' NAT routes still present:

· netstat -rn | grep 10\.211

· # Example output when broken:

· 10.211.55/24 link#XX UC bridge100 !

· 10.211.55.255 ff.ff.ff... UHLWbI bridge100 !

(So the bridge and routes remain.)

• But the NAT/DHCP daemon is not running:

· ps aux | grep prl_naptd | grep -v grep

· # (no output)

When working normally, I see a root-owned process like:

/Applications/Parallels Desktop.app/Contents/MacOS/prl_naptd start

Note on Parallels 26.x: the legacy vnic0/vnic1 interfaces no longer appear in ifconfig. Shared networking now runs over bridge100 with prl_naptd. So absence of vnic0/vnic1 is expected; the key signal is whether prl_naptd is alive.

Why I believe this is a Parallels bug

• The VM is healthy (reboots fix it).
• The host still shows the bridge100 routes for 10.211.55.0/24, but Parallels' DHCP/NAT daemon (prl_naptd) is gone.
• As soon as I restart the Parallels network layer (see "Fixes/Workarounds"), DHCP immediately works and the VM gets 10.211.55.x.
• The same VM on a different host (M4 Max with Ethernet present) has been solid for days, suggesting a host sleep/Wi-Fi + prl_naptd interaction on the M3 Max specifically.

This strongly points to prl_naptd crashing or failing to restart after host sleep on certain Apple silicon + Wi-Fi scenarios.

Further proof: Immediate recovery (no Mac reboot)

• Shut down all VMs (not Suspend).
• Parallels Desktop → Settings → Network → Restore Defaults → approve admin prompt.
• Start the VM → it instantly gets a 10.211.55.x address again.

This appears to relaunch prl_naptd and rebind to bridge100.

Technical Data Report submitted, #504431174