cezanne / usbip-win

USB/IP for Windows
GNU General Public License v3.0
1.92k stars 346 forks source link

Endpoint stalled if attached device is idle #272

Open skajacore opened 2 years ago

skajacore commented 2 years ago

Attaching remotely to a mouse, the device successfully attaches from Win 10 and the driver installs, as long as I keep moving the mouse wheel, it remains connected. If I leave it idle, an error on the host saying the endpoint stalled and the device stops working.

I've also tried this with a bluetooth dongle (my real application), and as long as it is scanning and trying to connect to nearby devices it remains connected, otherwise when idle, it connects and disconnects repeatedly until the USB Root Hub device throws an error that it could not reset. The USB device appears normally in device manager in the bluetooth group, at the time it is connected

Using a linux PC as usb host device. (usbip-utils 2.0)

The logs are pretty hard to understand for someone not familiar with the underlying code or protocol. I'd be happy to test and contribute to a fix, but I could use some pointers.

vhci_ude vhci_hc_c18 controller_query_usb_capability 4 25C 2 58 09\07\2021-13:27:51 VHCI TRACE_LEVEL_WARNING (WW)controller_query_usb_capability:not supported: a0e8d74a-4755-448a-96da-1a984cff7f6a

vhci_ude vhci_urbr_fetch_c111 handle_urbr_error 306C 2720 10 267 09\07\2021-13:27:51 WRITE TRACE_LEVEL_WARNING (WW)handle_urbr_error:usbd status:USBD_STATUS_STALL_PID: [urb,seq:18,URB_FUNCTION_CONTROL_TRANSFER]:

vhci_ude vhci_urbr_fetch_c111 handle_urbr_error 306C 2720 6 323 09\07\2021-13:27:51 WRITE TRACE_LEVEL_WARNING (WW)handle_urbr_error:usbd status:USBD_STATUS_STALL_PID: [urb,seq:23,URB_FUNCTION_CONTROL_TRANSFER]:

vhci_ude vhci_write_c49 write_vusb 306C 2720 4 27341 09\07\2021-13:27:58 WRITE TRACE_LEVEL_WARNING (WW)write_vusb:no urbr: seqnum: 0

usbip_vhci_ude.log

cezanne commented 2 years ago

@skajacore : I agree vhci log is not pretty good to understand. However, your log looks a bit more complicated. How did you extract it? Here is my log from TraceView.exe.

00000036        vhci_ude        4       6340    1       36      07\12\2021-05:58:33:744     store_urbr_urb:[urb,seq:2,URB_FUNCTION_CONTROL_TRANSFER_EX]
00000037        vhci_ude        4       6340    1       37      07\12\2021-05:58:33:744     submit_urbr:urb requested: [urb,seq:2,URB_FUNCTION_CONTROL_TRANSFER_EX]: 0x00000103(STATUS_PENDING)
00000038        vhci_ude        4       6340    1       38      07\12\2021-05:58:33:744     internal_device_control:Leave: 0x00000103(STATUS_PENDING)
00000039        vhci_ude        916     3964    1       39      07\12\2021-05:58:33:745     io_read:Enter: len: 48
00000040        vhci_ude        916     3964    1       40      07\12\2021-05:58:33:745     read_vusb:Enter
00000041        vhci_ude        916     3964    1       41      07\12\2021-05:58:33:745     io_read:Leave: 0x00000103(STATUS_PENDING)
00000042        vhci_ude        916     3964    1       42      07\12\2021-05:58:33:795     io_write:Enter: len: 52

Anyway, your first 3 warnings seem to be no problem but last warning logs are mysterious. The linux server might send wrong packets. Was there any clue in your usbip server ?

newprophet commented 1 month ago

@skajacore Did you fix the bug?