We are investigating bridged Wi-Fi DHCP behavior on recent macOS releases and would appreciate some clarification regarding the net.link.bridge.use_dhcp_xid sysctl.
We observed that with the default setting, DHCP packets transmitted from a virtual machine through a bridged Wi-Fi interface may have their DHCP client identity modified (chaddr). In our testing, setting:
net.link.bridge.use_dhcp_xid=0
prevents this behavior and restores the DHCP packet format observed on older macOS versions.
We would like to better understand the intended purpose of this sysctl:
What functionality does net.link.bridge.use_dhcp_xid control internally? Besides DHCP chaddr rewriting, what other bridge or DHCP processing behavior is affected by this setting? Is this sysctl related to DHCP snooping, anti-spoofing protection, Wi-Fi bridging compatibility, or another mechanism? Is the current default behavior (use_dhcp_xid=1) a recent change introduced in macOS 26.4.x? Is the modified DHCP behavior considered expected and supported, or is it intended as an implementation detail?
For additional context, we previously submitted feedback regarding DHCP handling for virtual machines using Virtualization Framework. Since packet modification is restricted from user space, we are wondering whether this sysctl is related to DHCP processing implemented by the bridge subsystem to address DHCP spoofing, client identification, or Wi-Fi bridging limitations.
One concern we have is that net.link.bridge.use_dhcp_xid appears to be a system-wide setting.
In our use case, DHCP handling requirements may differ between virtual machines, networks, and environments. As a result, changing a global bridge behavior for the entire host system is not always desirable.
If this sysctl is intended to control DHCP processing for bridged virtual machines, would it be possible to expose similar functionality on a per-interface, per-bridge, or per-VM basis rather than as a host-wide setting?
This would allow virtualization products to adapt DHCP behavior to specific network environments without affecting all bridged networking on the host.
One additional question:
Apple suggested making this setting persistent via /etc/sysctl.conf. However, this file does not exist by default on our macOS 26.4.x systems. Is /etc/sysctl.conf still a supported mechanism for persistent sysctl configuration, or is there a preferred modern alternative?
Any documentation or implementation details that can be shared would be greatly appreciated.
The net.link.bridge.use_dhcp_xid sysctl is only relevant when bridging to an interface that requires MAC-NAT, specifically a Wi-Fi STA interface.
The previous solution relied on setting the BROADCAST flag in the dp_flags field of the DHCP packet. That solution doesn't work with all DHCP servers, which is why there is an improvement/change made in 26.4.x and onwards.
The new solution is to re-write the DHCP dp_chaddr field with the MAC-NAT interface's hardware address, and use the DHCP transaction ID field dp_xid to de-multiplex the response.
The dp_xid based solution has a fallback mechanism whereby it should detect whether the DHCP server is assigning the same IP address as the Wi-Fi STA interface, and in that case, internally disable net.link.bridge.use_dhcp_xid for this specific bridge interface instance.
I have your feedback request (thank you!) and am still analyzing the logs to determine what can be done to improve this fallback mechanism. I will be updating that feedback request once I have completed the analysis.
Regarding /etc/sysctl.conf, yes, this is supported on macOS (see man sysctl.conf).
To disable the dp_xid solution by default, add a line to /etc/sysctl.conf:
net.link.bridge.use_dhcp_xid=0
