Summary
A VM using bridged networking cannot obtain an IP address when bridged to the host's Wi-Fi interface. Bridging the same VM to a wired Ethernet interface works normally.
Environment
- Tart:
2.34.0
- Host OS: macOS
26.5.2 (25F84)
- Guest: Debian (with Tart Guest Agent)
- Wi-Fi interface:
en0
- Wired interface:
en5
- Both host interfaces are connected to the same LAN and DHCP server
Steps to reproduce
Wi-Fi
tart run --no-graphics --net-bridged=en0 Debian
tart ip Debian --resolver agent
Result:
no IP address found (also make sure that Guest agent for Tart is running inside of a VM)
The guest does not receive a DHCP address.
Wired Ethernet
tart stop Debian --timeout 10
tart run --no-graphics --net-bridged=en5 Debian
tart ip Debian --resolver agent
Result: the guest receives an address from the LAN DHCP server and bridged networking works normally.
Expected behavior
The guest should receive a DHCP address and have network connectivity when Tart is started with --net-bridged=en0 or --net-bridged="Wi-Fi".
Additional diagnostics
The host Wi-Fi connection itself is healthy:
- The host receives a DHCP address on
en0.
- The gateway is reachable through
en0.
- Direct Internet access explicitly bound to
en0 works.
- Tart lists both
en0 and en5 as available bridged interfaces.
The host currently reports:
net.link.bridge.use_dhcp_xid: 1
net.link.bridge.check_dhcp_xid: 1
Recent macOS versions appear to have changed bridged Wi-Fi DHCP handling around net.link.bridge.use_dhcp_xid. I have not changed this system setting yet, but it may be relevant because only Wi-Fi bridging is affected.
Please let me know if packet captures, additional logs, or a test with net.link.bridge.use_dhcp_xid=0 would be useful.
Additional guest kernel evidence from the Wi-Fi bridged-networking failure:
virtio_net virtio0 enp0s1: NETDEV WATCHDOG: CPU: 1: transmit queue 0 timed out 45184 ms
virtio_net virtio0 enp0s1: TX timeout on queue: 0, sq: output.0, vq: 0x1, name: output.0, 45184000 usecs ago
This suggests that the guest's virtio_net TX queue stops completing transmissions for about 45.184 seconds when bridged to Wi-Fi, rather than this being only an IP-address discovery problem. The same VM bridges successfully over the wired en5 interface, where this warning was not observed.
Summary
A VM using bridged networking cannot obtain an IP address when bridged to the host's Wi-Fi interface. Bridging the same VM to a wired Ethernet interface works normally.
Environment
2.34.026.5.2(25F84)en0en5Steps to reproduce
Wi-Fi
Result:
The guest does not receive a DHCP address.
Wired Ethernet
Result: the guest receives an address from the LAN DHCP server and bridged networking works normally.
Expected behavior
The guest should receive a DHCP address and have network connectivity when Tart is started with
--net-bridged=en0or--net-bridged="Wi-Fi".Additional diagnostics
The host Wi-Fi connection itself is healthy:
en0.en0.en0works.en0anden5as available bridged interfaces.The host currently reports:
Recent macOS versions appear to have changed bridged Wi-Fi DHCP handling around
net.link.bridge.use_dhcp_xid. I have not changed this system setting yet, but it may be relevant because only Wi-Fi bridging is affected.Please let me know if packet captures, additional logs, or a test with
net.link.bridge.use_dhcp_xid=0would be useful.Additional guest kernel evidence from the Wi-Fi bridged-networking failure:
This suggests that the guest's
virtio_netTX queue stops completing transmissions for about 45.184 seconds when bridged to Wi-Fi, rather than this being only an IP-address discovery problem. The same VM bridges successfully over the wireden5interface, where this warning was not observed.