Device connects successfully but does not supply a /dev/cu.* on MacOS

First of saying I am very excited over being able to remotely upload firmware and doing development of an ESP-32 connected to my QNAP NAS (and bought license) even though unfortunately not working as anticipated.

I am currently running vhusbdx86_64 v3.4.7 on QNAP-NAS TS-431 (kernel 4.14.24)
And the VirtualHere Client 5.1.4 on MacOS Mojave (10.14.6)

This works perfectly fine when I connect an ESP-8266 to the NAS and being able to use this client to connect and does give a /dev/cu.wchusbserial110 that I can connect to which I imagine rule out the client being the problem.

Now when I connect an ESP-32 device and connect to it that shows me the following details

----
VENDOR: Silicon Labs
PRODUCT: CP2102 USB to UART Bridge Controller
VENDOR ID: 0x10C4
PRODUCT ID: 0xEA60
SERIAL: 0001
ADDRESS: 1123

You are using this device
---

But there is now new /dev/cu.xxxxx device as anticipated.
Now if I connect the same device locally it does give me such /dev/cu.SLAB_USBtoUART
So that must rule out the device and/or the SiLab driver 5.3.5 installed on MacOS (as client) that could be found here https://www.silabs.com/documents/public/software/Mac_OSX_VCP_Driver.zip

Now I have tested "uninstalling" the client (MacOS kext) and restarted and tested again, no success.
Per default on QNAP NAS there is no kernel-module loaded for cp2101, so what I also have tested is to load that module by
insmod /usr/local/modules/cp210x.ko

Then I get an /dev/ttyUSB0 that I could successfully connect to this ESP-32 on the NAS.

Then I have restarted the server using /share/CACHEDEV1_DATA/.qpkg/VirtualHere/control.sh
No difference ... with or without the silab (client) driver installed.

When I check the server logs I see no unusual and comparing while using an ESP-8266 connected (which works), the logs while connect to the ESP-32 I find on the server vhusbd

----
Mon Dec 21 09:53:17 2020 LOG_INFO Found Full speed device [10c4:ea60] "Silicon Labs, CP2102 USB to UART Bridge Controller" at address 1123
Mon Dec 21 09:54:19 2020 LOG_INFO 10.1.0.106 connected as connection 87
Mon Dec 21 09:54:34 2020 LOG_INFO Device 1123 [10c4:ea60] BOUND to connection 87
----

Doing "lsusb" on server I get the following detail
----
Bus 001 Device 051: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x Composite Device
----

Now on the client side (MacOS) I figured out you can manually start it with logging
/Applications/VirtualHere.app/Contents/MacOS/VirtualHere -l /tmp/vh.log

And in those logs I see
----
09:51:02 INFO :VirtualHere Client 5.1.4 starting (Compiled: Dec 13 2020 20:48:12)
09:51:02 INFO :Client OS is macOS Mojave Version 10.14.6 (Build 18G103)
09:51:02 INFO :Using config at /Users/edo/Library/Preferences/vhui Preferences
09:51:02 INFO :IPC available at /tmp/vhclient
09:51:02 INFO :Auto-find using Bonjour - on
09:51:02 INFO :Auto-find using Bonjour SSL - on
09:51:17 INFO :Carried and installed driver are both version 2.0.3
09:51:17 INFO :Successfully bound to driver
09:51:17 INFO :Connected to the VirtualHere Client Driver (Version 2)
09:51:53 INFO :OSXClientDriver shutting down...
09:51:53 INFO :Auto-find using Bonjour SSL - off
09:51:53 INFO :Auto-find using Bonjour - off
09:51:53 INFO :Connection 1 remotely disconnected gracefully (rx)
----
In fact can't tell a difference in the logs when connecting the ESP-8266 (that works without problem) with when I connect ESP-32 / CP2102..

Any theories what the problem might be? or what can one try next to remedy this?

BR,
Daniel

#2

But there is now new /dev/cu.xxxxx device as anticipated -> But there is NO new /dev/cu.xxxxx device as anticipated.

#4

Hi, I'm using almost the same device (CP2102N USB to UART Bridge Controller) with the same vendor and product id (just the "N" version) on a Linux server (GL-MT300N-V2) and I can use the device (a serial printer) without any problems on a Windows client using the latest drivers from the Silabs website.

#5

... thank you @Michael the device I currently use is a such "ESP32 development board" such as this one https://www.aliexpress.com/item/33037737422.html?spm=a2g0s.9042311.0.0…

It was a good advice upgrading the server from 3.4.7 to 4.2.0 that I now did, thought I was on the latest since the QNAP-store didn't propose newer one so installed this manually. Unfortunately I have the same symptom, I don't have the full understanding of how the "silab" driver differs from let say the driver that the ESP8266 uses (which I think is that "CH341SER" - http://www.wch.cn/download/CH341SER_MAC_ZIP.html) in the sense of recognising the device from VirtualHere client, perhaps you are on to something - but you think the problem need to be fixed in SiLab? And wondering if you or someone would know how to best explain in technical terms what SiLab might need to do to their driver to allow VirtualHere to fully support it?

Also thanks @MarkoD, now I currently only use MacOS - but with your comment it may also may prove that the problem is with the "SiLab MacOS" driver. Now it may be worth for me try to see if I can create a VM to try another platform, but at the end obviously I'd rather see the root cause being solved.

#6

Yeah i think you might have to use a windows client instead. I dont think the osx client will work