Custom NCM device being disabled by macOS

Question

Created 1w

Replies 7

Boosts 0

Participants 2

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.

Boost

Answer 1

DTS Engineer OP

Apple

1w

Can you file a bug on this and then post the bug number back here? As part of that bug, please upload a sysdiagnose for both the working and failing case.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 2

AckwelFoley OP

6d

Thanks - I have raised FB22704546 with a sysdiagnose as requested

0

Answer 3

DTS Engineer OP

Apple

5d

Thanks - I have raised FB22704546 with a sysdiagnose as requested

Can you upload the full USB trace files you included screenshots from (in your PDF)? The engineering team has a theory about what's going on, but they'd like to see full trace logs to confirm that.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 4

AckwelFoley OP

5d

Sure - just done this.

0

Answer 5

DTS Engineer OP

Apple

4d

Sure - just done this.

SO, here's what I've been told by the engineering team:

(1)

There is an issue (r.170072016) on the system's side of this, introduced as part of trying to fix a different issue with other hardware. I can't discuss if/when a fix will be released, but this is something they expect to eventually address.

(2)

If you want to get this working now, then try changing "bmNetworkCapabilities" of your NCM functional descriptor from "00" to "D0”:

Current Value:

06 24 1A 00 01 00

New Value:

06 24 1A 00 01 D0

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0

Answer 6

AckwelFoley OP

4d

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. So the host then tries to send a load of extended capabilities commands which my device doesn't understand.

Could you confirm whether macOS is compatible with NCM 1.0 devices? My device works just fine on Linux and Windows with their native NCM drivers.

Alternatively, is there a way I can get more debug information out of the NCM kernel extension to figure out what it's doing? I've tried:

sudo log config --mode "level:debug" --subsystem com.apple.driver.usb.cdc.ncm

but it made no difference.

0

Answer 7

DTS Engineer OP

Apple

3d

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

0