Application rejected connection

[galio]

Good morning,

I have several posts that seem to change their UUID for no apparent reason.

These machines appear disconnected in the console, and in the server logs I have:

Code: Select all

[waptws         ] WARNING Application rejected connection
[waptserver     ] CRITICAL Get_websocket_auth_token failed EWaptAuthenticationFailure('Unknown host UUID RND-2049E68D-A262-4C90-81AB-A1B714BC4BB4. Please register first.')
[waptws         ] WARNING SocketIO connection refused for uuid RND-2049E68D-A262-4C90-81AB-A1B714BC4BB4, sid 347b08d0406c412086dbd199ff6fbf9e: Unknown host RND-2049E68D-A262-4C90-81AB-A1B714BC4BB4, instance

I tried to register a machine and indeed its UUID changed; moreover, the format of this UUID is not the same (prefixed by RND-):

Screenshot from 2024-02-08 10-20-00.png (16.17 KB) Viewed 3566 times

What could be causing this problem? And, more importantly, how can I restore communication with my workstations that are not on-site?

THANKS.

[sfonteneau]

Hello,

you can upgrade to version 2.5.3 of Wapt, which should resolve this type of problem.

Simon

[dcardon]

Hello Stéphane,

WAPT uses the BIOS UUID returned by WMI by default. If WMI is not responding (because the WMI database is down, or for another reason), a random UUID can be retrieved (starting with RND-*).

We added several extra checks in WAPT 2.5 to address this issue.

Regarding your remote workstations, if the UUID changes, they should try to re-register with the WAPT server, unless you have a reverse proxy handling TLS termination and certificate validation. How did you configure the machine registration?

Best regards,

Denis

[galio]

Hello and thank you for your replies

I understand the RND-* UUIDs better now; I just checked the machine I re-registered, and the BIOS UUID given by WMI does indeed correspond to the old UUID:

Code: Select all

C:\Windows\system32>wmic path win32_computersystemproduct get uuid 
UUID                                  
4C4C4544-0033-3810-804A-C6C04F565033  

I have the same value in the wapt console, so wmi seems to be responding correctly.

There is no reverse proxy but registration requires authentication, that's why clients do not re-register.

I was looking at the logs to make sure everything was okay before doing the 2.5 update; if it helps to solve the problem, I'll do it quickly.

However, I don't see how to re-establish communication with the still-erroneous workstations. Will clients on version 2.4 change the UUID again if they manage to read the WMI database?

Sincerely