Error once a week/month (Error 22 discarding urb)

Submitted by MarkoD on #1

Hi Michael,

We are using the latest CloudHub (v 4.7.3) on a GL-AR300M16 with a USB-to-serial POS system (STMicroelectronics Virtual COM Port, HW ID: USB\VID_0483&PID_5740). We use a separately powered USB hub (from Amazon; one that supports port restarting) between the devices and the CloudHubs. The client version is 5.8.2 running on Windows 10 (as a service).

Very sporadically (once a week or month) we get a "Error 22 discarding urb" only once during the day:

Mon Jan 27 07:15:12 2025 user.warn vhusbdchglar300m16[1351]: Error 22 discarding urb 0x77eb4cb0 for device /sys/devices/platform/ahb/1b000000.usb/usb1/1-1/1-1.4, Invalid argument (abort endpoint)
Mon Jan 27 07:15:12 2025 user.warn vhusbdchglar300m16[1351]: Error 22 discarding urb 0x77eb4c80 for device /sys/devices/platform/ahb/1b000000.usb/usb1/1-1/1-1.4, Invalid argument (abort endpoint)
Mon Jan 27 07:15:12 2025 user.info vhusbdchglar300m16[1351]: Connection 45 remotely disconnected gracefully (rx msg size)
Mon Jan 27 07:15:20 2025 user.info vhusbdchglar300m16[1351]: Device 111 [0483:5740] UNBOUND from connection 45
Mon Jan 27 07:15:20 2025 user.info vhusbdchglar300m16[1351]: Device 114 [056a:00a8] UNBOUND from connection 45
Mon Jan 27 07:15:21 2025 user.info vhusbdchglar300m16[1351]: Connection 45 successfully removed (reason:timeout)
Mon Jan 27 07:15:30 2025 user.info vhusbdchglar300m16[1351]: 10.32.1.11 connected as connection 48 (Standard TCP)
Mon Jan 27 07:15:31 2025 user.info vhusbdchglar300m16[1351]: Executed "" for onReset.0483.5740
Mon Jan 27 07:15:31 2025 user.info vhusbdchglar300m16[1351]: Device 111 [0483:5740] BOUND to connection 48
Mon Jan 27 07:15:31 2025 user.info vhusbdchglar300m16[1351]: Executed "" for onSetConfiguration.0483.5740
Mon Jan 27 07:15:31 2025 kern.warn kernel: [2234436.524026] usb 1-1.1: usbfs: process 1390 (op111) did not claim interface 0 before use
Mon Jan 27 07:15:31 2025 kern.warn kernel: [2234436.538091] usb 1-1.1: usbfs: process 1390 (op111) did not claim interface 1 before use
Mon Jan 27 07:15:31 2025 kern.info kernel: [2234436.598344] usb 1-1.4: reset high-speed USB device number 4 using ehci-platform
Mon Jan 27 07:15:31 2025 user.info vhusbdchglar300m16[1351]: Device 114 [056a:00a8] BOUND to connection 48

Note that device 111 (0483:5740) is the POS system, and we are also using a Wacom signing tablet (device 114 056a:00a8, connected to the same USB powered HUB). Only the POS system is getting an error.

PS: We've used an older POS system (Silicon Labs CP2102N) for the last 4 years and have solved similar issues (we got a SURPRISE UNBOUND back in the day) by adding the USB-powered hubs along with setting an empty onReset command. However, there is no SURPRISE UNBOUND nowadays, but instead the Error 22 discarding urb. A workaround that fixes the issue is to just restart the Windows client (running as a service), without needing to power-restart the USB port on the hub.

Thank you for any ideas we can try and keep up the good work on VirtualHere!

Regards,

Marko

Submitted by Michael on Tue, 2025/01/28 - 07:38

#2

Hi Marko, at 07:15:12  connection 45 was dropped. When a connection is dropped it is because the network link was dropped momentarily or permanently (or the client exited). The server is saying that the client disconnected first.  When a connection is dropped, the server will attempt to cancel any outstanding transfers for that connection, that's why you see the abort endpoint messages. You would have to look back through the log to see what (connection 45) client IP this was but it was probably 10.32.1.11 because that reconnected so soon after.

So it seems the network is dropping and that is causing the devices to be disconnected from the client. I don't think its a good idea to skip the setConfiguration or the onReset events as they are probably needed. Is all this connected via Ethernet or WiFi? Keep an eye on the connection latency and that might point to WiFi interference (if you are using WiFi)

Submitted by MarkoD on Tue, 2025/01/28 - 08:21

#3

Thanks, Michael, for the explanation. The connection is via 1 Gbit/s ethernet (with 2 switches in-between), the latency is 1-5 ms, so that should be stable enough. But a brief network drop would explain this scenario? The client reconnected automatically, however the POS device was left in an unknown state (I got errors when I tried to communicate with it). However, after I restarted the client service, the device was okay. From the server's point of view, there should't be any difference between these 2 reconnects?

I've checked the logs on the client (via Event Viewer) and there were no VirtualHere events during that time slot. The closest event was when I restarted the VirtualHere service at 07:15:30.

PS: The 2 warning messages after the client reconnected ("usb 1-1.1: usbfs: process 1390 (op111) did not claim interface 0 before use") can be safely ignored or not?

Submitted by Michael on Tue, 2025/01/28 - 08:29

#4

The client log will log the drop and say something similar to :

"2025-01-27 08:25:54 INFO  :Server ping timeout, shutting down connection 7...
2025-01-27 08:25:54 INFO  :Connection 7 socket closed (rx)"

So that will be written in the Event Viewer log around that time. Alternatively you could redirect the log to a txt file instead of event viewer for easier debugging.
Uninstall the client service then install it like this vhui64.exe -i -l c:\path\to\log.txt

The did not claim message is no problem