-
Notifications
You must be signed in to change notification settings - Fork 29
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
Comments
Which USB devices are you using? This seems to be a device-specific request by Linux driver. You can find the definition of |
Hi @jiegec , |
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. |
I pushed code to master branch, could you please test? I don't have testbed for now. |
Thanks! I am indeed emulating an ftdi device. |
If you emulating in Rust code, you might need to implement the new trait |
yup - on it! Will contribute FTDI device handler when I have something that looks like it works... |
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. |
Hiya!
I have an app exposing a usbip virtual device and getting the following when running
sudo lsusb -v
from Linux: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?The text was updated successfully, but these errors were encountered: