search

AristoChen / usb-proxy

A USB proxy based on raw-gadget and libusb
Apache License 2.0
136 stars 29 forks source link

host to device transfer size #1

Open lmirel opened 2 years ago

lmirel commented 2 years ago

Hi, I've tested on Raspberry PI 4 and BeagleBone Black and on both there seems to be an issue with data from host to device. The issue may come from raw-gadget itself but I'm not sure what would be the right approach. It seems that when we get data from the host, it could contain more than just one packet (up to info.eps[i].limits.maxpacket_limit) which aside from the weird behavior on the actual device, it may also get lost when sent via libusb_interrupt_transfer in send_data (I'm unable to actually verify this on the device).

On BeagleBone Black I can see this when adding traces for data reception in ep_loop_read:

#PKT@253.250>481B/0x07/out
#PKT@253.367>545B/0x07/out
#PKT@253.487>481B/0x07/out
#PKT@253.611>545B/0x07/out
#PKT@253.734>545B/0x07/out
#PKT@253.854>481B/0x07/out
#PKT@253.974>481B/0x07/out
#PKT@254.094>481B/0x07/out
#PKT@254.213>481B/0x07/out 
#PKT@254.333>417B/0x07/out
#PKT@254.459> 33B/0x07/out
#PKT@254.578> 33B/0x07/out
#PKT@254.698> 33B/0x07/out

Meaning that at 253.250 (sec.ms) from starting the proxy it received 480 bytes (see first message - I added 1 byte because I am preserving the endpoint info for my own use). Sometimes the transfer size equals actual payload like in the last 3 cases where 32 bytes were received.

On BeagleBone Black, the maxpacket_limit is reported to be 512 for the EPs assigned for use via proxy. Any chance this can be tuned to only process one message at a time?

On Raspberry PI 4 the behavior is worse as it transfers 1024 bytes at a time most of the time and sometimes it gets blocked for a second with no transfer at all but the Raspberry PI is somewhat known to exhibit USB issues.

The transfers from device to host don't show any issue and they respect the expected message size.

Thanks in advance for any feedback

lmirel commented 2 years ago

solved it like this for lack of a better option. feel free to close this

AristoChen commented 2 years ago

Hi,

First of all, thank you for the interest in this project.

May I know what USB device you are using with this project? I would like to try to reproduce this issue if possible.

There are still some bugs and some code temporarily put there because I haven’t had enough time to think thoroughly yet or lack of relative experience, I will find some time to write a TODO in README.md in the future, and feel free to let me know if you found anything weird in the code, thanks!

lmirel commented 2 years ago

I use a gaming controller (steering wheel) to pick up the data and extrapolate some ‘telemetry’ for driving a motion platform see https://github.com/lmirel/mfc The controller is very fast, polling at 5ms and I had to tune the priority and remove the debug messages. I’ll update the tool as I tune it. rPI4 would have been perfect but it blocks the input endpoint for a few seconds at some point in time and that makes it unusable. You could try to reproduce that as I’m curious to see if my setup is the issue and not the rPI4. Thanks for your effort and this nice idea.