Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

not implemented: control in #7

Open
jamesadevine opened this issue Jan 31, 2023 · 9 comments · May be fixed by #8
Open

not implemented: control in #7

jamesadevine opened this issue Jan 31, 2023 · 9 comments · May be fixed by #8

Comments

@jamesadevine
Copy link
Collaborator

jamesadevine commented Jan 31, 2023

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
Copy link
Owner

jiegec commented Feb 1, 2023

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
Copy link

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
Copy link
Owner

jiegec commented Feb 1, 2023

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 added a commit that referenced this issue Feb 1, 2023
jiegec added a commit that referenced this issue Feb 1, 2023
@jiegec
Copy link
Owner

jiegec commented Feb 1, 2023

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

@jamesadevine
Copy link
Collaborator Author

Thanks! I am indeed emulating an ftdi device.

@jiegec
Copy link
Owner

jiegec commented Feb 1, 2023

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

@jamesadevine
Copy link
Collaborator Author

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

@jamesadevine jamesadevine linked a pull request Feb 1, 2023 that will close this issue
@beriberikix
Copy link

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
Copy link
Owner

jiegec commented Nov 2, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants