search

jiegec / usbip

A Rust library to run a USB/IP server
MIT License
306 stars 30 forks source link

not implemented: control in #7

Open jamesadevine opened 1 year ago

jamesadevine commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

jamesadevine commented 1 year ago

Thanks! I am indeed emulating an ftdi device.

jiegec commented 1 year ago

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

jamesadevine commented 1 year ago

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

beriberikix commented 4 weeks ago

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 commented 4 weeks ago

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.