NAK as a valid response in the hardware without the callback in the Python code

[DiagProf]

First of all, Cynthion and Facedancer are really an impressive achievement.

I have a trace from a USB device. When I try to emulate it with Facedancer, I can't get past a certain point.
The device has the following endpoint, which is called shortly after the entire configuration.

            class Endpoint_4_IN(USBEndpoint):
                number = 4
                direction = USBDirection.IN
                transfer_type = USBTransferType.INTERRUPT
                synchronization_type = USBSynchronizationType.NONE
                usage_type = USBUsageType.DATA
                max_packet_size = 64
                interval = 1
                extra_bytes = bytes([])

There is no response, which is perfectly fine for interrupt transactions, as described here: https://www.beyondlogic.org/usbnutshell/usb3.shtml under NAK.
"NAK - Reports that the device temporary cannot send or received data. Also used during interrupt transactions to inform the host there is no data to send."

But NAK is also an entry point to intervene with Python. And since this probably takes some time and the interval is 1ms, it seems to be occupied solely with this interrupt transfer procedure.

I wish I could set a flag on the interrupt endpoint so that an empty response can be handled by the hardware. It would be great if I could switch this later when a response needs to be handled in python.

I have also tried slowing down the polling interval (interval = 100), but it seems the driver doesn't take it into account.

Maybe there's already something in Facedancer, but I can't find it. Any help is welcome :-) Thanks.

[antoinevg]

I'm not sure I understand exactly what it is you'd like to do but I can try sharing a few things that may or may not be helpful!

• First off, NAKs are handled in hardware by the USB gateware which automatically respond to all data requests on IN endpoints with a NAK until that endpoint's FIFO has been 1) loaded with data to send back and 2) primed to respond.
• Facedancer uses the NAK status of IN endpoints to determine if it needs to call into your device emulation's handlers to provide some data.
• For Cynthion, this happens in the backend's service_irqs() method:

  facedancer/facedancer/backends/moondancer.py

  Lines 458 to 462 in 994cdf0

  	# Check EP_IN NAK status for pending data requests
  	else:
  	nak_status = self.api.get_nak_status()
  	if nak_status != 0:
  	self.handle_ep_in_nak_status(nak_status)

• If you wanted to handle IN endpoint NAKs manually you could maybe try commenting that section out and invoking the call to api.get_nak_status() yourself?

[DiagProf]

Maybe I'm doing something wrong. Is there a specific method I need to set if I don't want to send anything because I don't need to send anything?

If I don't do anything on EP4, nothing will be sent, right? Or does it need something explicit to indicate that I have nothing to send?

` class Endpoint_3_OUT(USBEndpoint):
number = 3
direction = USBDirection.OUT
transfer_type = USBTransferType.BULK
synchronization_type = USBSynchronizationType.NONE
usage_type = USBUsageType.DATA
max_packet_size = 512
interval = 0
extra_bytes = bytes([])

            def handle_data_received(self, data):
                print(f"Received data: {data}")


        class Endpoint_4_IN(USBEndpoint):
            number = 4
            direction = USBDirection.IN
            transfer_type = USBTransferType.INTERRUPT
            synchronization_type = USBSynchronizationType.NONE
            usage_type = USBUsageType.DATA
            max_packet_size = 64
            interval = 1
            extra_bytes = bytes([])

        class Endpoint_5_IN(USBEndpoint):
            number = 5
            direction = USBDirection.IN
            transfer_type = USBTransferType.BULK
            synchronization_type = USBSynchronizationType.NONE
            usage_type = USBUsageType.DATA
            max_packet_size = 512
            interval = 0
            extra_bytes = bytes([])

            def handle_data_requested(self):`

All my other endpoints basically stop working as soon as EP4 is called by the host. It seems like the application is stuck... but when I add this event handler, I see that it’s all about EP4, and the others EP(all bulk ) are never processed again.

` class Endpoint_4_IN(USBEndpoint):
number = 4
direction = USBDirection.IN
transfer_type = USBTransferType.INTERRUPT
synchronization_type = USBSynchronizationType.NONE
usage_type = USBUsageType.DATA
max_packet_size = 64
interval = 1
extra_bytes = bytes([])

            def handle_data_requested(self):
                print("Hallo from EP4")`

[antoinevg]

I'm starting to get a clearer picture, thank you for the additional information!

For an interrupt endpoint - if your device endpoint's handle_data_requested() is called you have two options:

1. Call self.send([...]) with a reply to the host's IN interrupt transfer request.
2. Do nothing and leave it up to the host to respond to the request timing out.

Where things get tricky is that it may not be clear which of 1 or 2 is appropriate for any given situation.

For example:

• A HID device such as a keyboard must respond to every interrupt transfer request with an HID report containing the state of the keyboard irrespective of whether a key is currently pressed or not.
• A USB audio device could happily do nothing in response to a bunch of interrupt transfers from the host as the host will simply make another request.

I think what might be happening in your instance is that the host is expecting a specific reply from your device's IN Interrupt endpoint and won't make any further requests until that happens.

There is also the possibility that Facedancer is unable to respond in time, I've found that sometimes it can take two or three IN transfer requests timing out before I have a reply ready. If the host driver is sensitive to that and won't issue multiple requests this could also cause a problem. We're working on improving Facedancer performance but there's always going to be some latency in the loop.

If you told me a bit more about the device you're emulating I may be able to assist further.

[martinling]

A HID device such as a keyboard must respond to every interrupt transfer request with an HID report containing the state of the keyboard irrespective of whether a key is currently pressed or not.

This isn't actually true. It's fine for a HID device to NAK an IN token if it doesn't have a new input report available at that time.

There is a requirement in HID 1.11 Appendix C that keyboards produce input reports at least as often as the current "idle rate", but that has specific meaning which is unrelated to the polling interval. This requirement is only there so that a driver can always determine the current state of the keyboard after waiting for at least one idle period. Otherwise a keyboard would be able to sit there indefinitely with a key being held down that the OS doesn't know about, because it missed/lost the report that would have told it that back when the key was pressed.

[DiagProf]

@antoinevg I would like to accept your offer and send you an email at info@greatscottgadgets.com with everything I have so far. I don't want to share it too publicly. Would that be okay with you? PS: The drivers are only available for Windows :-)

[antoinevg]

We only have limited capacity to provide engineering support and, as such, can only respond to questions publicly. This ensures that our resources go towards serving the entire community. Thank you for understanding!

[DiagProf]

I don't want you to do my work either (I enjoy doing it myself), but I believe it can't be solved with Facedancer. That's actually the only thing I'd like to have confirmed or disproven.

[martinling]

If the issue is that the host is requiring an immediate response, but Facedancer is having to NAK a few times before it can send your data, then in principle it may be possible to avoid that delay by providing the data before the host asks for it, i.e. by calling endpoint.send([...]) somewhere earlier during setup, rather than just in handle_data_requested.

Whether that actually works right now I'm not sure, but if it doesn't, that's something I'll probably be trying to fix soon.