search

dorssel / usbipd-win

Windows software for sharing locally connected USB devices to other machines, including Hyper-V guests and WSL 2.
GNU General Public License v3.0
3.64k stars 231 forks source link

usbmuxd[11535]: [12:02:18.961][1] device_control_input: ERROR (on device): asyncReadComplete, message was too large (65536 bytes, max = 6 #867

Open Mark6222 opened 8 months ago

Mark6222 commented 8 months ago

is there a file size limit

dorssel commented 8 months ago

No, not within usbipd-win.

Maybe due to the extra delay introduced by the USBIP protocol, some reads arrive close together, and usbmuxd is not expecting that. For example: reads are requested 40kB per request. For local USB (real hardware) these requests and their replies are spaced apart normally. But due to USBIP some are completed slightly late, such that they arrives close to the next. And maybe usbmuxd then gets 2×40kB in a single read (just example numbers). Just guessing, though.

Mark6222 commented 8 months ago

how would i fix something like that

dorssel commented 8 months ago

First, try to see if this is indeed the problem. Make a capture while reproducing, see https://github.com/dorssel/usbipd-win/wiki/Troubleshooting. You can improve the timing (only a bit) by opening task manager and giving the usbipd.exe service process realtime priority.

Mark6222 commented 8 months ago

Hi Dorssel, I've believe the issue is to do with usbipd on the windows side as ive tested sideloading an app onto the phone from two Linux boxes using usbip and its worked. ive attached the troubleshooting file below. log.zip

Mark6222 commented 8 months ago

setting the priority didn't fix the issue

dorssel commented 8 months ago

Yes, it is because of the packet latency introduced by usbipd. Linux does everything in the kernel, and therefore has much better timing. usbipd-win requires user mode software (the drivers themselves do not handle the network USBIP protocol). Therefore, the per packet timing has much more variance. Not really a bug, but unfortunately by design. Your logs show exactly what I meant earlier; the individual packets are not too large (49216 per packet, on line 485 and 489). This is not something that can be fixed.

Mark6222 commented 8 months ago

do you know of any other way to accomplish what I'm trying to do, as this is a brick wall for my project.

dorssel commented 8 months ago

You could try to increase the buffer size of usbmuxd; maybe it's configurable, or else modify the source. From a USB perspective everything seems to be working, it's just that the software on the client cannot handle the timing/bunching of data. Otherwise, I see no options other than to use the device on a native Linux platform instead of forwarding it from Windows.