Issues with usbip-win on windows 10

[melg8]

Hi, i really like your project, but i came across some issues.

So my setup is - windows 10, i installed usbip-win version 0.3.5 from https://github.com/cezanne/usbip-win. I try to run localy keyboard example on native windows 10.

When i tried to use your repo, i got problems when running keyboard example:

1. when calling '''./usbip attach -r 127.0.0.1 -b 0''' example doesn't detect bus, because usbip-win sends bus id in format like "0\0fefefefefe..." - and you check for "0\0\0\0\0\0\0..." I've fixed it by checking if one bus sctring contains another.
2. than it doesnt work - and get stuck in loop, reporting wrong packet requests from client. I've found solution for that by manualy replacing: 0x02, // bcdUSB: USB 2.1 value with 0x01, // bcdUSB

and self.ep0_in.max_packet_size as u8, // bMaxPacketSize0 with 0x08, // bMaxPacketSize0

I found that values by trying mimic python/c baced repo, which works with usbip-win.

Now, i have one last problem, which i don't know how to fix. When i run example - it runs, it creates new HID keyboard device, and even sends 1 as input... But, it doesn't just send one "1" per second - it's like spams it. (like 10-20 characters per second).

So, question is, where i can get compatible version of usbip-win client which works correctly with your example (and on win 10). Or, what i should additionaly change to fix the issue of auto-repeated characters, on busy server (i've observed, that when server doesn't reply for like 250ms it starts to spam last character. My goal is to have something like: 127x0x0x1 string outputed fast, and than - to do nothing for next ten seconds, than repeat. And my ultimate goal is to have syncronous api which i can call something like PressKey("A"); ReleaseKey("A"); from thread with logic, imitating human input.

Trying to wrap my head around this issue for last few days with no luck...

I'm really new to rust and usbip/hid so any help or suggestions are appreciated.

[jiegec]

The protocol of USBIP is not well documented, and I only worked this repo towards the implementation of usbip under Linux.

[jiegec]

I don't have a windows development environment at hand now, so if you are interested, you are welcome to make this library compatible to usbip-win.

[jiegec]

when calling '''./usbip attach -r 127.0.0.1 -b 0'''
example doesn't detect bus, because usbip-win sends bus id in format like "0\0fefefefefe..." - and you check for "0\0\0\0\0\0\0..."
I've fixed it by checking if one bus sctring contains another.

0xFE seems to be the filling byte on stack on Windows. You can submit your patch for the fix. I shouldn't have checked the string after NUL byte.

[jiegec]

than it doesnt work - and get stuck in loop, reporting wrong packet requests from client. I've found solution for that by manualy replacing:
0x02, // bcdUSB: USB 2.1
value with
0x01, // bcdUSB

It might be that usbip-win and windows request some USB 2.1 specific requests. Downgrading to USB1.1 would be an option, and this should be specified by the user.

[jiegec]

And my ultimate goal is to have syncronous api which i can call something like PressKey("A"); ReleaseKey("A"); from thread with logic, imitating human input.

This could be done in a producer-consumer design: one thread pushes the event into a queue, and the usb handler thread popes event from the queue.

[jiegec]

and
self.ep0_in.max_packet_size as u8, // bMaxPacketSize0
with
0x08, // bMaxPacketSize0

If I recall correctly, USB 2.0 and USB1.1 have different constraints on max packet size.

[melg8]

@jiegec Thankgs for replies! So, linux version on which you tested it doesn't have problem with auto-repeating key strokest after server doesnt reply long enough? How you suggest to fix issue with too big cpu usage on server work? Is there any data in protocol, which could reduce number of message exchanges between client-server?

[jiegec]

I am not expert on USB, either.

[shymega]

I've forked this project to be used with my hybrid sw/hw KVM. I intend to add encryption support, and @melg8, if you have any patches that fix these issues, do you think you could make a PR, either here, or to my fork - or both? Thanks.

I also plan to submit my changes back here, but I'm thinking on how to add encryption as an optional feature. The idea with my hybrid KVM is to support Windows, *nix, and macOS.

[shymega]

Actually, having said that, I don't think it'll be easy to add encryption without breaking the existing protocol. What I may do is a partial refactor, rename the repo to something like usbip-ng, and redesign the protocol with msgpack, maybe. The Sourceforge usbip driver being last updated in 2011 on the site is a bit of a concern too.

[jiegec]

Yes, the original usbip protocol seems unchanged for a long time and operating system support is distributed in different projects e.g. usbip in mainline linux, usbipd-win etc.

[shymega]

Yeah, I'm redoing a driver. I need something that's encrypted, as this hybrid KVM will communicate over a potentially unsecured network, and writing it in Rust might provide some safety too... but not necessarily. It's in a workspace on the org.