windows 10 as USBIP client about usbip-win

[cezuni]

@yelfarri I think that there's no problem in usbip protocol related code.
16777216 in network byte order means 1 in host byte order.
It is just a problem in usbip userland printing routine.

Does seems that the pdu header is getting wrong value. This values should be between 1-4 do you have the same issue ?

usbip: info: from_swapped value = 0
usbip: info: swap_usbip_header_endian cmd value = 16777216
usbip: error: unknown command in pdu header: 16777216

In my case the device is regonized as a HID device. There is some improvement that good :).

Improved but windows vhci driver still is not working. I'm working. 😅

[cezuni]

I don't know what the actual information on the device is, but they're zero on Linux itself
BDeviceClass = 0;
BDeviceSubClass = 0;
BDeviceProtocol = 0;

@wrenchonline Many devices have zeros in device descriptor.(I got to know through this issue)
Those zero class/protocol means they should be assigned from USB interface descriptor.

@wrenchonlin for usbip in server mode Linux does not assign values for BDeviceClass , BDeviceSubClass, and BDeviceprotocol . It is the client that signs those values. When running Linux-host to Linux-client, you can notice the same behavior where the client sets those values.

@yelfarri AFAIK, original Linux code resolves those values via additional listing command when importing. But recent linux kernel(over 4.13 ??) does not seem to provide interface info when a device is not configured. So listing command does not help.

9d72a1a code assigns class/subclass/protocol values from direct usbip protocol.

[cezuni]

@yelfarri , @wrenchonline : You mean that it takes too long to work? 3 hours or 20 minutes.
That may be another issue. My usb stick and mouse over usbip work after 20~40 seconds.
However, my bluetooth dongle has a problem. Its failure is due to that a USB internal IRP is cancelled when usbip command exceeds 500msec. I suspect that this cancellation is done by a upper function driver.

[maurice-stegmann]

@yelfarri : I've tested a usb mouse and usbip on the client side behaved strange...
As I listed the devices my Mouse has shown up as expected:

C:\usbip>usbip.exe list -r 172.22.0.212
Exportable USB devices
======================
 - 172.22.0.212
      1-1.3: Microsoft Corp. : Comfort Mouse 4500 (045e:076c)
           : /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3
           : (Defined at Interface level) (00/00/00)

After I tried to attach the devices I've got no console output and wasn't able to quit the process hitting ctrl + c or closing the console window or quitting usbip by task manager.

In Device Manager USB over IP is listed as system device. Heres a Screenshot of the details:

I'm so sorry for bothering...

[cezuni]

Is this ab bug of this repository as you mentioned in last line of README that it did not work?

Yes..

I had focused to windows usbip server and something in vhci driver went wrong.
I'll check out until this year ends.

[dhyanisumit12]

Are there compatibility issues with USBIP between linux and windows version. As in linux its showing version : usbip (usbip-utils 2.0)
But the library you are providing is showing : 1.0.0

[cezuni]

#3 may answer your question. Protocol negotiation will fail between different versions.
But usbip-utils 2.0 you mentioned seems to be an only autoconf package version.
It's not related to usbip protocol.
This repo has 0x111 USBIP_VERSION, which is a up-to-date version. (Kernel 4.20.x has the same USBIP version)

[yelfarri]

Thank you for your answer. I understand that more testing is needed but I m trying to help in any way possible. I can test some devices if you don't mind :). So from my understanding your Bluetooth dongle in
working windows?
I have tested your code on different mice and keyboards I have the same problem as described in the one here #6. Seems that issue with the Vhci_pdo.c and/or vhci_PnP.c . I have done some attempt find and fix the issue but without any luck.

I used Kernel debugging to get access log output from VHCI it seems that the BUS_PNP = STATUS_NOT_SUPPORTED in four cases. Are they cause for the issue ?

00005098 4676.33251953 usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFD68AE85A8980
00005099 4676.33251953 usbip_vhci: Query GUID: EC92E9B897A7C44D884684D041707446
00005100 4676.33251953 usbip_vhci: Query unknown interface GUID:
00005101 4676.33251953 usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED

00005123 4676.33349609 usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFD68AE85A8980
00005124 4676.33349609 usbip_vhci: QueryId Type: BusQueryContainerID
00005125 4676.33349609 usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED

00005127 4676.33349609 usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFD68AE85A8980
00005128 4676.33349609 usbip_vhci: Query GUID: 0E1B2170FB0ADB47AFC1410BF842497A
00005129 4676.33349609 usbip_vhci: Query unknown interface GUID:
00005130 4676.33349609 usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED

00005142 4676.33398438 usbip_vhci: Bus_PnP: Enter
00005143 4676.33398438 usbip_vhci: PDO: minor: IRP_MN_QUERY_RESOURCES, IRP: 0xFFFFD68AE85A8980
00005144 4676.33398438 usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
00005145 4676.33447266 usbip_vhci: Bus_PnP: Enter

[cezuni]

I don't mind but your help makes me be hasty. ^^;; Many thanks to you.

Serious error or warning logs have (E) or (W) prefix.
Did your logs have no such prefix?

If up-to-date vhci codes still have "USB Device Over IP" in device manager,
your mentioned STATUS_NOT_SUPPORTED may be the cause for this issue.

[yelfarri]

Thank you. I m happy that your working on this! :)

No there is no severe error or warning with a prefix (E) or (W) in my log. The only issue is that the "USB Device Over IP" is classified by windows under other devices. The status of this device drivers is " device is not installed"(see the 1st picture in this post). When checking a bit closer in the events tab (USB Device Over IP Properties), we see that the device has not acquired any configurations. That confirms my suspension that that vhci_pdo.c does not initialize the new device correctly. Based on the log I trace the messages back to the following functions in the code.

The status STATUS_NOT_SUPPORTED can be tracked back to the file vhci_pdo.c spesificly those three cases below.
Why does that occur i m not sure. Is it not configured correctly ? or does it expect that it will receive configurations from linux ?

//Line 1255 in vhci_pdo.c
case IRP_MN_QUERY_INTERFACE:
		//
		// This request enables a driver to export a direct-call
		// interface to other drivers. A bus driver that exports
		// an interface must handle this request for its child
		// devices (child PDOs).
		//
		status = Bus_PDO_QueryInterface(DeviceData, Irp);
		break;

//Line 1194 in vhci_pdo.c
case IRP_MN_QUERY_ID:
		DBGI(DBG_PNP, "QueryId Type: %s\n", dbg_bus_query_id_type(IrpStack->Parameters.QueryId.IdType));

		status = Bus_PDO_QueryDeviceId(DeviceData, Irp);
		break;

//Line 1209 in vhci_pdo.c
case IRP_MN_QUERY_RESOURCES:

		status = Bus_PDO_QueryResources(DeviceData, Irp);

		break;

As mentioned in the earlier post here i still see the same

When I right click to check the events of the USB Device over IP, I see the following. There is no configuration for the devices.

[cezuni]

Below is my log when a bluetooth dongle in linux is successfully attached from win10.
What's different?

usbip_vhci: ioctl code: IOCTL_USBIP_VHCI_PLUGIN_HARDWARE
usbip_vhci: Exposing PDO: addr: 1, vendor:product: 0b05:1715
usbip_vhci: fdodata->NextLowerDriver = 0xFFFFDE8D20590E40
usbip_vhci: pdo 0xFFFFDE8D22B31350, extension 0xFFFFDE8D22B314A0
usbip_vhci: Bus_PnP: Enter
usbip_vhci: FDO: minor: IRP_MN_QUERY_DEVICE_RELATIONS, IRP:0xFFFFDE8D208B2E10
usbip_vhci:  QueryDeviceRelation Type: BusRelations
usbip_vhci: # of PDOS: present: 1, reported: 1
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D20D68880
usbip_vhci: QueryId Type: BusQueryDeviceID
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_CAPABILITIES, IRP: 0xFFFFDE8D20D68880
usbip_vhci: Bus_PnP: Enter
usbip_vhci: FDO: minor: IRP_MN_QUERY_CAPABILITIES, IRP:0xFFFFDE8D208B2E10
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_DEVICE_TEXT, IRP: 0xFFFFDE8D20D68880
usbip_vhci:  DeviceTextDescription :USB Device Over IP
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_DEVICE_TEXT, IRP: 0xFFFFDE8D20D68880
usbip_vhci:  DeviceTextLocationInformation :on USB/IP VHCI
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D20D68880
usbip_vhci: QueryId Type: BusQueryInstanceID
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D20D68880
usbip_vhci: QueryId Type: BusQueryHardwareIDs
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D20D68880
usbip_vhci: QueryId Type: BusQueryCompatibleIDs
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D20D68880
usbip_vhci: QueryId Type: BusQueryContainerID
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_Ioctl: Leave: STATUS_SUCCESS
usbip_vhci: Bus_Read: Enter
usbip_vhci: Bus_Read: Leave: STATUS_PENDING
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFDE8D20D68880
usbip_vhci: Query GUID: 0E1B2170FB0ADB47AFC1410BF842497A
usbip_vhci: Query unknown interface GUID:
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_BUS_INFORMATION, IRP: 0xFFFFDE8D20D68880
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_RESOURCE_REQUIREMENTS, IRP: 0xFFFFDE8D2477F010
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_RESOURCES, IRP: 0xFFFFDE8D2477F010
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_DEVICE_ENUMERATED, IRP: 0xFFFFDE8D2477F010
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: QueryId Type: BusQueryDeviceID
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_CAPABILITIES, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Bus_PnP: Enter
usbip_vhci: FDO: minor: IRP_MN_QUERY_CAPABILITIES, IRP:0xFFFFDE8D22780010
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_DEVICE_TEXT, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci:  DeviceTextDescription :USB Device Over IP
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_DEVICE_TEXT, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci:  DeviceTextLocationInformation :on USB/IP VHCI
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: QueryId Type: BusQueryInstanceID
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: QueryId Type: BusQueryHardwareIDs
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: QueryId Type: BusQueryCompatibleIDs
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: QueryId Type: BusQueryContainerID
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Query GUID: 0E1B2170FB0ADB47AFC1410BF842497A
usbip_vhci: Query unknown interface GUID:
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_BUS_INFORMATION, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_RESOURCE_REQUIREMENTS, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_RESOURCES, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Query GUID: EA98EEDEA1C0C3429738A04606C84E93
usbip_vhci: Query unknown interface GUID:
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Query GUID: 136AA9B1E03D74459B01C08FEAB318D6
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: IsDeviceHighSpeed called, it is 2
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_LEGACY_BUS_INFORMATION, IRP: 0xFFFFDE8D22BF1E10
usbip_vhci:(WW) not handled: IRP_MN_QUERY_LEGACY_BUS_INFORMATION
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_QUERY_RESOURCE_REQUIREMENTS, IRP: 0xFFFFDE8D22BF1E10
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_FILTER_RESOURCE_REQUIREMENTS, IRP: 0xFFFFDE8D22BF1E10
usbip_vhci:(WW) not handled: IRP_MN_FILTER_RESOURCE_REQUIREMENTS
usbip_vhci: Bus_PnP: Leave: STATUS_NOT_SUPPORTED
usbip_vhci: Bus_PnP: Enter
usbip_vhci: PDO: minor: IRP_MN_START_DEVICE, IRP: 0xFFFFDE8D22BF1E10
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: Bus_Internal_Ioctl: Enter
usbip_vhci: ioctl code: IOCTL_INTERNAL_USB_SUBMIT_URB
usbip_vhci: process_irp_urb_req: function: URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE
usbip_vhci: store_urbr: urbr: [seq:1]
usbip_vhci: store_urbr_submit: urbr: [seq:1]
usbip_vhci: process_urb_req_submit: urbr: [seq:1], func:URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE

[cezuni]

@wrenchonline: I'm not sure but problems at IRP_MN_QUERY_DEVICE_RELATIONS or IRP_MN_QUERY_CAPABILITIES may not be related to this issue.
Can you share your logs or check if following lines are appeared?

usbip_vhci: PDO: minor: IRP_MN_QUERY_ID, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: QueryId Type: BusQueryHardwareIDs
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS

and

usbip_vhci: PDO: minor: IRP_MN_QUERY_INTERFACE, IRP: 0xFFFFDE8D22BC6CC0
usbip_vhci: Query GUID: 136AA9B1E03D74459B01C08FEAB318D6
usbip_vhci: Bus_PnP: Leave: STATUS_SUCCESS
usbip_vhci: IsDeviceHighSpeed called, it is 2
usbip_vhci: Bus_PnP: Enter

[cezuni]

With my usb stick, I have the same result with logs from @wrenchonline.
The reason why USB stick is not recognized is that
PNP manager does not invoke IRP_MN_QUERY_INTERFACE with USB_BUS_INTERFACE_USBDI_GUID.
And such a no action of PNP manager may be due to wrong compatible IDs of USBIP device
which are all zeros.

I'll modify userland usbip code.

[yelfarri]

@wrenchonline and @cezuni I think the issues start from the usbip.exe file. When debuging usbip i see that the issues start in the userspace.

User ip>usbip.exe --debug attach -r -b 1-1
For the sake of testing where can i set a default value to check if that is the cause of the issues ? is udev struct used to pass the values to other functions ?

usbip: debug: c:..\usbip_vhci.c:57:[usbip_vhci_driver_open] device path: \?\root#unknown#0000#{d35f7840-6a0c-11d2-b841-00c04fad5171}
usbip: debug: c:..\usbip\usbip_attach.c:55:[import_device] got free port 1
usbip: debug: c:..\usbip\usbip_vhci.c:121:[usbip_vhci_attach_device] plugin.devid: 65538

usbip: debug: c:..\usbip\usbip_vhci.c:122:[usbip_vhci_attach_device] plugin.vendor: 2362

usbip: debug: c:..\usbip\usbip_vhci.c:123:[usbip_vhci_attach_device] plugin.product: 9488

usbip: debug: c:..\usbip_vhci.c:124:[usbip_vhci_attach_device] plugin.version: 256

usbip: debug: c:..\usbip\usbip_vhci.c:125:[usbip_vhci_attach_device] plugin.speed: �

usbip: debug: c:..\usbip\usbip_vhci.c:127:[usbip_vhci_attach_device] plugin.inum: �

usbip: debug: c:..\usbip\usbip_vhci.c:128:[usbip_vhci_attach_device] plugin.class:

usbip: debug: c:..\usbip\usbip_vhci.c:129:[usbip_vhci_attach_device] plugin.subclass:

usbip: debug: c:..\usbip\usbip_vhci.c:130:[usbip_vhci_attach_device] plugin.protocol:

usbip: debug: c:..\usbip\usbip_vhci.c:131:[usbip_vhci_attach_device] plugin.addr: �

[cezuni]

@yelfarri You can test with a following workaround. The values are from my USB stick.

diff --git a/userspace/src/usbip/usbip_attach.c b/userspace/src/usbip/usbip_attach.c
index f7f51ff..942d2fe 100644
--- a/userspace/src/usbip/usbip_attach.c
+++ b/userspace/src/usbip/usbip_attach.c
@@ -115,6 +115,11 @@ static int query_import_device(SOCKET sockfd, const char *busid, HANDLE *phdev)
                return 1;
        }
 
+       /* manual setting from the values of lsusb -v in linux box */
+        reply.udev.bDeviceClass = 8;
+        reply.udev.bDeviceSubClass = 6;
+        reply.udev.bDeviceProtocol = 80;
+
        /* import a device */
        return import_device(sockfd, &reply.udev, phdev);
 }

[cezuni]

9d72a1a makes a device to be recognized.
But my usb stick does not seem to be working. 😢

[yelfarri]

@wrenchonline that is odd, can you test with a mouse or keyboard ? i have the follow configurations. Do you have the same issue mouse or keyboard ?

/*3 - Human Interface Device */
BDeviceClass = 3;
/* 1 - Boot Interface Subclass */
BDeviceSubClass = 1;
/* 1 - Keyboard*/
/* 2 - Mouse */
BDeviceProtocol = 2;

@wrenchonlin for usbip in server mode Linux does not assign values for BDeviceClass , BDeviceSubClass, and BDeviceprotocol . It is the client that signs those values. When running Linux-host to Linux-client, you can notice the same behavior where the client sets those values.

From @Oxalin usbip I understood that earlier Linux-host set values than send them over to the client. I have tested that approach, and it worked for a short period but...... both windows and Linux becomes unstable (BSOD@windows and Linux crashes).

[yelfarri]

@cezuni i have downloaded your latest commit 9d72a1a and done testing on your user code. Its definitly regonising the device now. Mouse and keyboard keeping it simple at the moment.

Does seems that the pdu header is getting wrong value. This values should be between 1-4 do you have the same issue ?

usbip: info: from_swapped value = 0
usbip: info: swap_usbip_header_endian cmd value = 16777216
usbip: error: unknown command in pdu header: 16777216

In my case the device is regonized as a HID device. There is some improvement that good :).

Information from device manager-> usb input device properties

Device USB\Vid_093a&Pid_2510\1&1aafb3d5&b&0001 had a problem starting.

Driver Name: input.inf
Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
Service: HidUsb
Lower Filters:
Upper Filters:
Problem: 0xA
Problem Status: 0xC0000120 // stands for The I/O request was canceled.

[yelfarri]

@cezuni I have some good news and some bad news. Today i have been doing some testing on the system. I decided that I will reinstall the driver and test again. I m using a USB mouse in Linux host with windows client. And it worked!! It is stilling working after 3 hours running.
The bad news I have no idea why!

One thing i reliazed when i attach the device on windows i have to move the mouse so windows driver manage to recognized it as a hid device.

[yelfarri]

@cezuni my bad I mean, it works at once and I had a connection running for 3 hours and everything was ok. I will add logs tomorrow :) if u need to take a look at them.

I was going to test a USB storage tomorrow.

[yelfarri]

Yeah, my mouse works after seconds too. I will take a look at USB storage tomorrow. Can you provide the device descriptor you are testing? I will try to find something similar to test

[cezuni]

@yelfarri : I cannot acquire exact device descriptors. Those devices are unplugged now.(I am at home)
My mouse for testing is a common MS optical and USB stick is 1GB unbranded one.
Here are lsusb results of my bluetooth dongle which is plugged:

Bus 001 Device 011: ID 0b05:1715 ASUSTek Computer, Inc. 2045 Bluetooth 2.0 Device with trace filter
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          224 Wireless
  bDeviceSubClass         1 Radio Frequency
  bDeviceProtocol         1 Bluetooth
  bMaxPacketSize0        64
  idVendor           0x0b05 ASUSTek Computer, Inc.
  idProduct          0x1715 2045 Bluetooth 2.0 Device with trace filter
  bcdDevice            1.00
  iManufacturer           1 
  iProduct                2 
  iSerial                 0 
  bNumConfigurations      1

I think that a specific device does not incur a problem.
If a certain type of device is working, every device in the same USB class(such as storage, network, HID..) also works.

[yelfarri]

@yelfarri Ha,ha.This is a little bit the same problem I raised last time in another project. I think how to scientifically debug is to know the problem.
In fact, Oxalin/usbip_windows#12. All my devices will work on his project, but some will have to wait too long

@wrenchonline what devices do you need do you have a list that we might need to work our way through?

@cezuni will create a test plan that will go through a certain type of devices classes so we will try to expose any type of bugs or issues in the system.

[maurice-stegmann]

Hello,
what am I doing wrong or what is causing this error?
Today I've compiled the Project without any errors and installed the driver.

As I try to attach a device I'm getting following errors:
*error: recv op_common
*error: failed to read: err:6

Attaching the same device from a linux machine works fine.

You can see a screenshot from my output below:

[cezuni]

@maurice-stegmann : What is a version of linux box? Can you share a linux kernel log?

[cezuni]

@wrenchonline : I think that usb speed mismatch is not the problem.
Your queue full error may imply that a usbip server does not respond to commands sent by a client.

They can't quit normally.my usb stick 3.1 . The computer jack is 2.0. Is it related to usb speed driver configuration?

You can increase queue length from below code but it will not resolve the problem.
https://github.com/cezuni/usbip-win/blob/27ec58531963eeca4d679a7ad70e705f00bdb4e4/userspace/lib/usbip_forward.c#L251

What is a compatible id of usbip device which can be obtained from detailed tab of property sheet ?
I want to check that class/subclass/protocol are still all zero's even if you apply up-to-date repo.

[cezuni]

@wrenchonline : Well, if larger queue length helps, there's a significant speed gap between usbip server and client. 2048 queue size would be sufficiently large but waiting for a free usbip command seq slot instead of returning with error will be a more desirable approach. This can be a new issue.

It works much better.A few usb pop tests were good.But it will still prompt out queue full.

Is the meaning of "pop" in pop tests "unplugging" a USB device?

[maurice-stegmann]

@cezuni : My Linux box is a RaspberryPi 3b+ running kernel 4.9.80 and Raspbian Stretch.

Here's an output of my kernel log:
[65987.848511] usbip-host 1-1.2: usbip-host: register new device (bus 1 dev 6)
[66103.920006] usbip-host 1-1.2: stub up
[66104.065842] usbip-host 1-1.2: usb_set_interface done: inf 0 alt 0
[66104.065942] usbip-host 1-1.2: endpoint 0 is stalled

[yelfarri]

@maurice-stegmann I need to ask first did you do the following steps?
Are you sure that the driver is been installed properly ?
Did you put windows in test signing mode ?
run usbip.exe from the folder that contains the following files.
first follow the steps under seems that the usbip can not find the file name name usb.ids. Than try to attach without using --debug.

Copy usbip.exe, usbip_vhci.sys, usbip_vhci.inf, usbip_vhci.cer, usbip_vhci.cat, usb.ids, usbip_stub.sys, usbip_stub.inx into a folder in target machine

You can find usbip.exe, usbip_vhci.sys, usbipd.exe, usbip_stub.sys  usbip_vhci.cer, usbip_vhci.inf in output folder.
usbip_vhci.cat can be found from usbip_vhci subfolder of output folder
userspace/usb.ids
driver/stub/usbip_stub.inx
You can find usbip.exein output folder.

[maurice-stegmann]

@yelfarri : I've installed the driver by adding a legacy device in device manager. I've also copied checked wether the correct files are in the same folder as usbip.exe. Still getting the same error...

Is it possible that I did something wrong during building?

[yelfarri]

@maurice-stegmann From linux side do you do the follow?
I m not sure can you check the time stamp one your generated files?

sudo modprobe vhci-hcd
driver >sudo modprobe usbip-core
Start usbip deamon >sudo usbipd -d
Bind usb device that will be used >sudo usbip bind -b Device ID

[maurice-stegmann]

@yelfarri :

check the time stamp one your generated files?

Do you mean the date of the files in the usbip directory on windows client machine?
I've tried Building this morning again so the time of the outputted files is right:

Binding on Linux machine worked properly worked properly.

 @raspberrypi:~ $ sudo usbip list -l
 [...]
 - busid 1-1.2 (058f:6387)
   Alcor Micro Corp. : Flash Drive (058f:6387)
 [...]
pi@raspberrypi:~ $ sudo usbip bind -b 1-1.2
usbip: info: bind device on busid 1-1.2: complete

[yelfarri]

@maurice-stegman
Can you test something other than usb flash drive, such as a mouse ? does it work for you ?
for testing one again can you show me how driver looks like on device manager ?
The image under is as an example.... i dont have access to my pc to test this at moment.

[yelfarri]

@maurice-stegmann no worries mate you are not bothering me. This is good we need to find any bugs related to the driver :). Does mouse show up under hid devices?

To disconnect in windows you have to open the other cmd and write

usbip.exe detach -p 0

than Ctrl + c will work and it will quit the software nicely

[maurice-stegmann]

Yes, the Mouse shows up after attaching but it's not useable.

Driverdetails:

[yelfarri]

@maurice-stegmann Everything is looking good for far....Can you create a new rule for windows firewall where the TCP port 3240 should be allowed for inbound and outbound traffic

I managed to recreate your issue here. In my case my driver seems not to function

[maurice-stegmann]

@yelfarri : The firewall on my windows machine was disabled during testing so I don't think that firewall is causing issues.

[maurice-stegmann]

@yelfarri : This morning, testing attaching the pendrive I've tried before:

@raspberrypi:~ $ sudo usbip list -l
[...]
- busid 1-1.2 (058f:6387)
  Alcor Micro Corp. : Flash Drive (058f:6387)
[...]

resulted in:

[yelfarri]

@maurice-stegmann sorry for the slow replay I was busy moving to a new apartment and as well trying to find the issue. I installed clean windows and did the same steps to install the driver. I have got the same issue as you did. I fixed it by doing the following.

Delete your old driver

Verify that your driver is removed.
Navigate to C:\Windows\System32\drivers and search for usbip_vhci.sys.
delete usbip_vhci.sys
Restart your Windows 10...

run cmd as administrator and paste those commands

bcdedit.exe -set load options DISABLE_INTEGRITY_CHECK
bcdedit.exe -set TESTSIGNING ON

Than restart...

Install usbip_vhci certificate, to local machine. Certificate should be installed into "Trusted Root Certification Authority" and "Trusted Publishers"

Install driver/usbip_test.pfx(password: usbip)
Certificate should be installed into "Trusted Root Certification Authority" and "Trusted Publishers" on local machine(not current user)

Copy usbip.exe, usbip_vhci.sys, usbip_vhci.inf, usbip_vhci.cer, usbip_vhci.cat into a folder in target machine. The files should be in the same folder

Install USBIP vhci driver

Than restart...
Use usbip.exe

[maurice-stegmann]

@yelfarri : I've tried your fix but I'm getting the same result as it was before. I've tested an USB pen drive, a mouse and a com to usb adaptor. Wich types of devices where you testing?

[yelfarri]

@maurice-stegmann i have tested a mouse, keyboard and joystick. Seems that issue happen when the driver is not installed properly. But i really have no idea why it happens in your pc. you get the follow water mark on the bottom right corner of your windows ?

[maurice-stegmann]

@yelfarri Yes, I get this watermark.
Where you able to use mouse, keyboard and joystick, after you attached them? On my machine, the mouse driver loaded properly but I just wasn't able to use it (click or move coursor).

[cezuni]

@maurice-stegmann : If a mouse pointer is not moved on usbip client, something goes wrong.
Your problem does not seem to be a just mis-configuration.

On my machine, the mouse driver loaded properly but I just wasn't able to use it (click or move coursor).

Windows and linux kernel logs would be helpful to find the problem. Or usbip forwarding debugging logs. You can just define DEBUG_PDU in following code.
https://github.com/cezuni/usbip-win/blob/27ec58531963eeca4d679a7ad70e705f00bdb4e4/userspace/lib/usbip_forward.c#L33

[yelfarri]

@maurice-stegmann at least we went through every configuration I could think of. Yeah, I manage to use them as if they were connected to the client pc. Can you provide the debugging logs as @cezuni suggested?

[maurice-stegmann]

@cezuni excuse me, how do i define DEBUG_PDU? I've removed the # wich resulted in build errors

[yelfarri]

@maurice-stegmann just add

#define DEBUG_PDU //<<<< add this
#ifdef DEBUG_PDU

[hubbybob2015]

@yelfarri Ha,ha.This is a little bit the same problem I raised last time in another project. I think how to scientifically debug is to know the problem.
In fact, Oxalin/usbip_windows#12. All my devices will work on his project, but some will have to wait too long

this project Oxalin/usbip_windows#12，I would like to know if the usb camera can work in windows client successsfully?

[yelfarri]

@hubbybob2015 Sorry but I have no idea... Maybe @wrenchonline can answer that

[yelfarri]

@cezuni can you close this issue it seems that it is resolved :). The USBIP client works as a client

[keirlessmi]

hello,
plz where i can find usbip_vhci.sys, usbip_vhci.inf,
thank you

[keirlessmi]

hello
how can i generate the project to get the files
thank you

[cezuni]

@keirlessmi : There's builtin binaries. Check release page. And Readme.md is the best for usbip-win build guide. 😄

[keirlessmi]

@cezuni thank you for the answer

[svirot]

Hello,
Similar problem (probably) whilst trying to use a PL2303 (USB to Serial converter) from a Linux server to a Windows client. In a nutshell, it gives the same "Code 10" error with the proprietary driver and comparing the USB messages from Wireshark, the first difference is a lack of "GET STATUS Request" (i.e. URB_FUNCTION_GET_STATUS_FROM_DEVICE) when using usbip. I have more details if it can help.
Given the 7a92e8e commit essentially simulates the status request/reply for the driver side, the PL2303 hardware probably needs that status request to progress in its initialisation process. This may be confirmed by the next command in the stream, a "SET CONFIGURATION" to which the device (through usbip) replies with blanked data (of the same size than the request buffer).
I guess adding the feature properly would need an update to the server side as well, meaning patching the Linux kernel which would make it tricky.
Please do not hesitate to ask if there is anything I can help with.
Thanks for the great with you put into this project.

[cezanne]

@svirot :

Given the 7a92e8e commit essentially simulates the status request/reply for the driver side, the PL2303 hardware probably needs that status request to progress in its initialisation process

That's a good point. 👍 Why don't you create another issue ?

[muhammadhaqyaunoora]

Hello everybody. Sorry if it is such a bother, but I got a similar problem like you guys and have tried all solutions you wrote here but still stuck with the same problem. Can anyone help me with it? Thank you in advance.

[cezanne]

@muhammadhaqyaunoora : What's your device ? This issue is too old. You'd better add a comment on a recent similar issue or create a new your own issue.

[muhammadhaqyaunoora]

Sorry for the late reply. I use a Raspberry Pi 3 for the server and an Asus laptop for the client. I tried to connect to Arduino Uno and the device manager only read it as a USB over IP. Also, when I checked on the list the information is just all unknown wherein the raspberry pi all of the information showed up. Does it counts as a new issue though? Sorry for the bother

[cezanne]

@muhammadhaqyaunoora : New issue would be preferable.

[muhammadhaqyaunoora]

Alright, I will create new issue then. Thank you