I have a custom-developed USB NCM device for a networking use case. My device is successfully enumerated by macOS at the USB layer, and it issues a USB SET_INTERFACE(altsetting = 1) to enable the NCM layer, but sometimes (about 50% of the time), the Mac then issues a USB SET_INTERFACE(altsetting = 0), which disables the interface. It never issues a SET_INTERFACE(altsetting = 1) command to re-enable it. In Network settings, the device just stays in the "Disconnected" state forever.
For context, the NCM specification says that all NCM devices must have two "alternate settings" at the USB interface level. Altsetting 0 is the default "disabled" startup state where no data endpoints are enabled, and altsetting 1 is the "enabled" state where data IN/OUT endpoints are enabled and packets can be transferred.
The NCM spec also says that SET_INTERFACE(altsetting=0) can be used by the host to 'reset' the NCM layer of the device back to known settings. I suspect this is what the Mac is trying to do, though it only does it 50% of the time. The remainder of the time, the device stays in altsetting 1 and traffic works just fine.
My question is, how can I get to the bottom of why the Mac is sometimes sending the SET_INTERFACE(altsetting=0) command or, if this behavior is usual, why is it not then re-enabling using SET_INTERFACE(altsetting=1) ? "log stream --info --debug" shows no information on this, and the NCM driver is a closed-source kernel extension so I have no visibility of what it's doing and why.
I've sniffed the USB bus using a packet analyzer and can't see anything odd there (no timing issues or dropped packets etc).
Any tips would be appreciated. I'm on Tahoe 26.4.1. I really don't want to develop a custom driver for this device and would prefer to operate with the native NCM driver.
So I tried changing the bmNetworkCapabilities to 0xD0 as suggested, but that means that bit 7 is set ("Function supports extended NCM 1.1 capabilities") which my device doesn't - it is an NCM 1.0 device.
Sorry about that, I was jumping around on a few different issues and messed up the example above. All you need to do is set "D0" of the bitfield, so you're declaring support for "SetEthernetPacketFilter". So that would be (assuming you're not setting an other bits):
06 24 1A 00 01 01
To clarify what I expect/hope setting that will do:
-
macOS will see the bit and send "SetEthernetPacketFilter" (basically, to confirm functionality).
-
Your accessory will fail the command (because you don't actually support it).
-
macOS will see the failure and then proceed normally (because there's already code in place to handle devices that behave like this).
I can't guarantee that will work, but the engineering team thinks that it will.
Could you confirm whether macOS is compatible with NCM 1.0 devices?
Yes, it is. Also, to be clear, the change above is specifically a workaround. I don't know if/when a fix will ship, but the engineering team does agree that this is a bug and that a value of 0x00 should "just work". The approach above is simply a workaround.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
