not implemented: control in

[jamesadevine]

Hiya!

I have an app exposing a usbip virtual device and getting the following when running sudo lsusb -v from Linux:

Control IN setup=SetupPacket { request_type: c0, request: a, value: 0, index: 1, length: 1 }
thread 'tokio-runtime-worker' panicked at 'not implemented: control in'

First, I'm not entirely sure what the 0xc0 request type is, any ideas? Second, it seems a bit harsh to simply panic - on a normal USB device I think it is conventional to stall? Is there a usbip equivalent that could be implemented instead?

[jiegec]

Which USB devices are you using? This seems to be a device-specific request by Linux driver.

You can find the definition of 0xc0 at https://www.beyondlogic.org/usbnutshell/usb6.shtml#SetupPacket

[khacluongspk]

Hi @jiegec ,
I faced same issue. My usb device is USB uart (0403:6010 Future Technology Devices International Limited Dual RS232-HS)
Did you test with usb serial device?

[jiegec]

Hi @jiegec , I faced same issue. My usb device is USB uart (0403:6010 Future Technology Devices International Limited Dual RS232-HS) Did you test with usb serial device?

I see, the linux ftdi driver generates the request:

#define  FTDI_SIO_GET_LATENCY_TIMER_REQUEST_TYPE 0xC0
#define FTDI_SIO_GET_MODEM_STATUS_REQUEST_TYPE 0xc0
#define FTDI_SIO_READ_PINS_REQUEST_TYPE 0xc0
#define FTDI_SIO_READ_EEPROM_REQUEST_TYPE 0xc0

Will try to fix this. Currently I don't have a FTDI serial at hand, I can access one later this month.

[jiegec]

I pushed code to master branch, could you please test? I don't have testbed for now.

[jamesadevine]

Thanks! I am indeed emulating an ftdi device.

[jiegec]

If you emulating in Rust code, you might need to implement the new trait UsbDeviceHandler to handle the requests.

[jamesadevine]

yup - on it! Will contribute FTDI device handler when I have something that looks like it works...

[beriberikix]

Curious to know if this discussion went anywhere. I think I'm running into a related issue testing various IoT development boards. Most have either an FTDI, Silicon Labs (ex. CP2102) or compatible USB to serial adapter. These all have vendor subclasses, though they are common enough to be in tree.

When I try the host example, I see empty packets in tests when I would expect data. The exact same hardware worked correctly in my tests worked using the native usbip server.

Does that mean we need to implement handlers for every vendor subclass? Fortunately there's not that many, but mostly trying to understand if I'm going down the right path.

[jiegec]

Curious to know if this discussion went anywhere. I think I'm running into a related issue testing various IoT development boards. Most have either an FTDI, Silicon Labs (ex. CP2102) or compatible USB to serial adapter. These all have vendor subclasses, though they are common enough to be in tree.

When I try the host example, I see empty packets in tests when I would expect data. The exact same hardware worked correctly in my tests worked using the native usbip server.

Does that mean we need to implement handlers for every vendor subclass? Fortunately there's not that many, but mostly trying to understand if I'm going down the right path.

The ftdi handler is meant to implement an emulated devices instead of sharing a real one. For the host example, there should be some missing pieces of USB/IP protocol not implemented good enough for it to work. Actually, similar problems exist for a long time for other types of complicated USB devices, but we need an expert to fix this.