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

[Mark6222]

is there a file size limit

[dorssel]

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]

how would i fix something like that

[dorssel]

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]

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]

setting the priority didn't fix the issue

[dorssel]

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]

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]

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.