Issues with vhclientx86_64 binary console client

Sorry that my first port is a bunch of questions and issues I have.

I have setup on Raspberry PI the VirtualHere USB Server for Linux (ARM) binary and it is started as deamon
As first trial I used a Windows to have the GUI Client version. There I can see and use the USB decives as expected.
It works like a charm and on same level as our very expensive Dige AnywhereUSB boxes.

Now I switched to an Ubuntu 14 server system (no desktop) where the console client will be used "VirtualHere USB Console Client for Linux (amd64)" vhclientx86_64

1. issue:
I have not started the client in daemon mode but tried vhclientx86_64 -t HELP and got back
No response from IPC server
The I have read related posts about that the client needs to be started first as daemon with option -n

2. issue:
After the client runs in background as daemon, I try to send command USE,

There is only a blank empty line and nothing happens, the command -t LIST shows that the device was not connected.
There is no warning in console client about the trial mode.

3. issue:
There is another post, that in case of console client, the server part does not have to run as daemon, thus I stopped the server ans started the binary directly.
I tried again point 2 but with no success.

4. issue:
I stopped the client daemon and tried once more directly command -t LIST and got back now
IPC stat failed, error 2 (No such file or directory)
Compared to 1. issue something changed now and my system has some hidden configuration?
Now -t HELP gets the same new response

Which client version I'm using? Since ther is no option -v, --version, I have to start first the client daemon and then -t HELP shows me the version v3.1.6.Please provide a direct --version option
Same for the server binary, as there is no version option.

6. issue:
Our use case will be that several same usb card reader are plugged to the server. In GUI client I can use context menu "Properties" to see the used USB Port and several clients will access the same server.
Is it possible to show that detail as default in GUI and console version? Otherwise it is hard to identify the usb port, assigned to me, as I have to go through the list of devices first.

7. issue:
To get a separation of each card reader, I would like to use the rename function that I have some unique nick names "Cardreader@Port1","Cardreader@Port2","Cardreader@Port3",.....
But if I switch the devices from one usb port to another the nick name is lost and not longer shown. After switching back the nick name is shown again.
How does the name mapping works? Can you determine the serial number of a device to provide the unique name over all usb ports?

8. issue:
Licensing was explained enough and I endorse with your decision. The only question is what happens if the SAME hardware gets a new scratch installation. Detects the software with some magic generator a new id and the paid licence is gone?
Or is it bundled to some hardware ids which will stay active the licence? (like in windows the amount of changed hardware impact to the current key)

Some more detailed questions will come up if my company is willing to buy some license :-)


Hi, to use the linux console client with the free server version of virtualhere, do the following

* open an terminal and type sudo ./vhclientx86_64
* open another terminal and use that to issue commands like this

e.g ./vhclientx86_64 -t LIST

e.g./vhclientx86_64 -t USE,12345678 etc

Item 5 : type ./vhclientx86_64 -h the version is at the top (or actually any invalid argument will show that)

Item 6: It shows the name of the person and their ip address of who is using the device when you use the LIST command

Item 7: In theory usb devices have a unique serial number, but most manufactures dont implement this and some use the same serial for their entire batch. Especially cheap card readers, So there is no guaranteed way to identify a usb device for nickname reasons, hence i just use the vendorid/productid and address

8. The key is the cpu serial number burned into the pi broadcom cpu. That number never changes no-matter what software is put on the pi so you can use the same license. If you get another pi however then that key will not work anymore and it will go back to trial.


Thank you for the instruction how the client works / has to be started, too. The client is connected now and is using the card reader device.

For issue 1 and 4 I would propose for a better user response improvement, that the console client mentions in addition something like "Please start client first before sending commands to it"
And in case of daemon and in trial mode, that each passed "USE" command gets back a "nag information" ;-) which will explicitly say that this feature is not usable in trial mode. The GUI client is much more communicative here.

A general request is, that the console client gets back on StdOut a success message. Currently I have to re-check with -t LIST if the device was connected or not.


Issuing a USE request is *not* a synchronous operation. It may fail for several reasons (e.g device is taken in the mean-time, server/network goes down etc), therefore you need to poll the list command for e.g 5 seconds to see if it got connected.