CloudHub with client as service, multiple disconnections during the day

Submitted by MarkoD on #1

Dear Michael, I'm using the CloudHub version 4.0.8 on multiple GL-MT300N-V2 with just one device (Silicon Labs, CP2102N USB to UART Bridge Controller) connected directly to each unit's USB port, without any USB hubs.

The clients are all running VirtualHere version 4.9.5 on Windows 7 Pro x64 in Hyper-V virtual machines, all devices are connected to the same LAN (latency is 1-2 ms). I have all the VirtualHere clients running as Windows services with Auto-Use Device turned on.

The CloudHub logs show a couple of reconnections that occur a couple of times (however, only on some days):

Mon Jan 13 19:07:35 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] UNBOUND from connection 9
Mon Jan 13 19:07:36 2020 user.info vhusbdchglmt300nv2[979]: Connection 9 successfully removed (reason:timeout)
Mon Jan 13 19:08:39 2020 user.info vhusbdchglmt300nv2[979]: 10.32.1.12 connected as connection 18
Mon Jan 13 19:08:40 2020 kern.info kernel: [1037210.115011] usb 2-1: reset full-speed USB device number 2 using ohci-platform
Mon Jan 13 19:08:40 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] BOUND to connection 18
Mon Jan 13 20:31:29 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] UNBOUND from connection 18
Mon Jan 13 20:31:30 2020 user.info vhusbdchglmt300nv2[979]: Connection 18 successfully removed (reason:timeout)
Mon Jan 13 20:31:39 2020 user.info vhusbdchglmt300nv2[979]: 10.32.1.12 connected as connection 20
Mon Jan 13 20:31:41 2020 kern.info kernel: [1042191.297426] usb 2-1: reset full-speed USB device number 2 using ohci-platform
Mon Jan 13 20:31:41 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] BOUND to connection 20
Mon Jan 13 20:31:53 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] UNBOUND from connection 20
Mon Jan 13 20:31:54 2020 user.info vhusbdchglmt300nv2[979]: Connection 20 successfully removed (reason:timeout)
Mon Jan 13 20:32:07 2020 user.info vhusbdchglmt300nv2[979]: 10.32.1.12 connected as connection 22
Mon Jan 13 20:32:07 2020 kern.info kernel: [1042217.747387] usb 2-1: reset full-speed USB device number 2 using ohci-platform
Mon Jan 13 20:32:08 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] BOUND to connection 22
Mon Jan 13 20:48:57 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] UNBOUND from connection 22
Mon Jan 13 20:48:58 2020 user.info vhusbdchglmt300nv2[979]: Connection 22 successfully removed (reason:timeout)
Mon Jan 13 20:49:06 2020 user.info vhusbdchglmt300nv2[979]: 10.32.1.12 connected as connection 24
Mon Jan 13 20:49:07 2020 kern.info kernel: [1043236.925891] usb 2-1: reset full-speed USB device number 2 using ohci-platform
Mon Jan 13 20:49:07 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] BOUND to connection 24
Mon Jan 13 21:14:20 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] UNBOUND from connection 24
Mon Jan 13 21:14:21 2020 user.info vhusbdchglmt300nv2[979]: Connection 24 successfully removed (reason:timeout)
Mon Jan 13 22:55:00 2020 user.info vhusbdchglmt300nv2[979]: 10.32.1.12 connected as connection 26
Mon Jan 13 22:55:04 2020 kern.info kernel: [1050793.895156] usb 2-1: reset full-speed USB device number 2 using ohci-platform
Mon Jan 13 22:55:04 2020 user.info vhusbdchglmt300nv2[979]: Device 21 [10c4:ea60] BOUND to connection 26

Note that the VMs are running 24/7, but the software that communicates with the USB devices is running only a couple of hours a day. The disconnections often happen during the evening when the software gets closed by the users (VirtualHere keeps running as a serivice in the background).

Does VirtualHere have a timeout when the client does not do anything? If not, what could be causing the client disconnections? All ethernet cables are okay, so it should not be a network issue.

PS: Would using onReset.$VENDOR_ID$.$PRODUCT_ID$= help in at least not resetting the USB devices when the client disconnects? Or perhaps ClaimPorts=1 on the CloudHubs?

Thanks for any tips!

Marko

Submitted by Michael on Fri, 2020/01/17 - 09:46

#2

Hi Marko, no VirtualHere doesn't have any timeouts, the connection should stay available all the time and not drop unless there is some network issue. You probably dont need to skip a reset but if you want to - yes use those settings.

Im wondering if it might be some power issue. Just for a test if you can, could you put a powered hub between the cloudhub and the com port device and see if that power separation resolves the issue. Note that you cant use ClaimPortswhen you are using a usb hub.

Give that a try and let me know if that resolves.

Submitted by MarkoD on Fri, 2020/01/17 - 11:18

#3

Thanks for the suggestions, we'll try and let you know. The USB devices should not need any more power than the standard USB port provides (5V 0.5A), so maybe the GL-MT300N-V2 may have problems with that? We're using 5V 2.1A USB chargers to power the units.

In order to prevent resets, is the custom onReset... event enough as-is, or does the ClaimPorts setting help in any way?

Thanks!

Submitted by Michael on Fri, 2020/01/17 - 11:24

#4

onReset... will prevent resets occuring. ClaimPort will prevent the initial SET CONFIGURATION 1 being sent. This actually is probably what you want so just put the onReset... in there only

Submitted by MarkoD on Sat, 2020/01/18 - 07:59

#5

Thanks, Michael, I'll try setting only the onReset... event. I've also found a couple of disconnect events with "rx msg size" as the reason:

user.info vhusbdchglmt300nv2[1112]: Connection 1 remotely disconnected gracefully (rx msg size)

Do you know what might be the cause of that? It says "gracefully", so is this a normal disconnect?

Submitted by Michael on Sat, 2020/01/18 - 10:21

#6

The remote connection logging is in the client USB Hubs->System Messages it will write the reason there why its disconnecting.

(The client might have exited by someone right clicking USB Hubs->Exit) that is usually the reason