Cheers kevin, filed 2 bugs documentation: FB23530504 the header/doc inconsistency: kFeatureHardwareVlan is referenced in the getVlanTag()/setVlanTag() doc comments in IOUserNetworkPacket.iig but defined nowhere in the public SDK (exhaustive grep: 4 hits, all doc comments). suggestion: FB23562845, the enhancement request for a public hardware VLAN capability, with the usecase detail you asked for included. I also ran the experiment you suggested, declaring IF_HWASSIST_VLAN_TAGGING (0x00010000) via getFeatureFlags() on macOS 26.3.1, with live tagged traffic on a vlan(4) interface over the driver: Alongside kIOUserNetworkHWAssistSoftwareVlan: no behavioral change. getVlanTag() never returns true; tags remain inline in both directions. Alone: also ignored and the vlan(4) child clamps to MTU 1496, i.e. the unpublished bit doesn't even receive the VLAN-MTU accounting the published bit provides. It's discarded wholesale, not partially honoured. One refinement to "I think you'll find that we strip the value": in our testing neither SetHardwareAssists (NDK_21) nor the mask-based setHardwareAssists (NDK_22) was ever invoked by the system in any configuration, so nothing gets stripped in a setter; whatever consumes the getFeatureFlags() output simply ignores unknown bits Empirically our results match your hyptohesis. On "why hardware-level support": to be clear, software VLAN works and is what we ship and it works. However, our request is about parity and efficiency, not functionality. This chip does VLAN offload in its RX/Tx descriptors used by both its previous macOS kext (which advertised the iokit equivalent of kIONetworkFeatureHardwareVlan) and the linux driver. Under D/kit, every tagged frame has the 802.1Q header inline through the data path and the hardware's VLAN filter/strip engine must stay disabled. since the dataplane API (get/setVlanTag) already shipped, publishing the control-plane capability would let IOKit-era drivers migrate without losing it. anyway, appreciate your response on this. enjoy your weekend.

The solution is to create a new profile. You cannot add new entitlements to an existing profile. You may need to unlink the profile from any apps before you can delete it and replace it.

I am experiencing this same HTTP 500 issue when requesting driver kit entitlements exactly as described. filed case ID 102830620344.

[message to moderator] I accidentally marked my own reply as accepted answer. Can you undo this action

For clarification , the "spoofed" hardware is just a simple STM microcontroller that is flashed to impersonate the descriptors of the real USB hardware, with the key difference that I removed the CDC-ECM descriptor.