We are trying to configure remote connections to a AnywhereUSB/14 hub using the C++ API library under “Advance” directory.
At the moment we have been able to connect to the Hub successfully, but, and this is the problem, we were only able to do it to Group 1 (Marked as default in the UI Admin console).
We need to be able to select which group we want to connect, as we will have each port mapped to a single group and in each of those ports we will have different devices.
According to the headers file in the same directory “AwUsbApi.h” this is done by appending the group number as a port to the remote IP (e.g. 192.168.1.10:3 where 3 stands for Group number 3)
But in the PDF under the same directory, this configuration is missing, which makes me think that is something experimental that somebody forgot to remove from the Code Documentation.
Funny is that the UI utility is able to do it, I mean to connect to a particular group as opposite to the C++ API.
Did someone knows how to do it?
Driver version: 3.80.200
C++ API revision: “Revision: 2 Date: 2009-10-07 22:01:17Z” ?? This comes from the headers file, but in it also is listed a 3 revision? Difficult to say…
SO: Virtual Box running a Windows 7 32 bits.
When using the C++ API if I pass “10.0.0.1:2” as the Hub IP address (IP is not real, just an example) I expect it to connect to group number 2, but what I saw when testing it is that it connects to group number 1 instead.
I guess that the reason is that the C++ API is not parsing the group number properly and then it uses the Default Group as defined in the Web UI, I cannot verify if this is true, though, as the Default Group is disabled in the Web UI.
Using the desktop application, I was able to connect to group 2 without problems, though.
I have good news, everyone. I expect to get an updated AWUSB API .dll very soon, hopefully sometime today, otherwise this coming Monday. Once I have it, I’ll provide a link for you to download then test it. Thanks so much for your continued patience!
I know I am very late to replying to this, but “better late than never”, I hope. I want to let you (and everyone else) know that this issue should be fixed in the .dll that is bundled with the latest AWUSB driver.