Thanks for your reply jc35, I'm looking forward to your feedback on the Nightly build.
Cheers!
[BUG 2.1 ??] Machines seen as DISCONNECTED since update 2.1
Forum Rules
Community Forum Rules
* English support on www.reddit.com/r/wapt
* French community support is available on this forum
* Please prefix the topic title with [RESOLVED] if it is resolved.
* Please do not edit a topic that is tagged [RESOLVED]. Open a new topic referencing the old one.
* Specify the installed WAPT version, full version, and build number (2.2.1.11957 / 2.2.2.12337 / etc.) as well as the Enterprise/Discovery edition.
* Versions 1.8.2 and earlier are no longer supported. The only questions accepted regarding version 1.8.2 are related to upgrading to a supported version (2.1, 2.2, etc.).
* Specify the server OS (Linux/Windows) and version (Debian Buster/Bullseye - CentOS 7 - Windows Server 2012/2016/2019).
* Specify the OS of the administration/package creation machine and the machine with the problematic agent, if applicable (Windows 7/10/11/Debian 11/etc.).
* Avoid asking multiple questions when opening a topic, otherwise it may be ignored. If there are multiple topics, open separate topics, preferably one after the other and not all at the same time (i.e., do not spam the forum).
* Include code snippets, screenshots, and other images directly in the post. Links to Pastebin, Bitly, and other third-party sites will be systematically removed.
* As with any community forum, support is provided voluntarily by members. If you require commercial support, you can contact Tranquil IT's sales department at 02.40.97.57.55
Community Forum Rules
* English support on www.reddit.com/r/wapt
* French community support is available on this forum
* Please prefix the topic title with [RESOLVED] if it is resolved.
* Please do not edit a topic that is tagged [RESOLVED]. Open a new topic referencing the old one.
* Specify the installed WAPT version, full version, and build number (2.2.1.11957 / 2.2.2.12337 / etc.) as well as the Enterprise/Discovery edition.
* Versions 1.8.2 and earlier are no longer supported. The only questions accepted regarding version 1.8.2 are related to upgrading to a supported version (2.1, 2.2, etc.).
* Specify the server OS (Linux/Windows) and version (Debian Buster/Bullseye - CentOS 7 - Windows Server 2012/2016/2019).
* Specify the OS of the administration/package creation machine and the machine with the problematic agent, if applicable (Windows 7/10/11/Debian 11/etc.).
* Avoid asking multiple questions when opening a topic, otherwise it may be ignored. If there are multiple topics, open separate topics, preferably one after the other and not all at the same time (i.e., do not spam the forum).
* Include code snippets, screenshots, and other images directly in the post. Links to Pastebin, Bitly, and other third-party sites will be systematically removed.
* As with any community forum, support is provided voluntarily by members. If you require commercial support, you can contact Tranquil IT's sales department at 02.40.97.57.55
-
Christophe0110
- Messages: 53
- Registration: June 11, 2019 - 12:04
Thanks for your feedback!
Yes, so in my opinion, my problem won't be solved since this is what happens in my case when the user leaves their docking station (connected via a network cable) and therefore switches to Wi-Fi to go to the meeting room...
I suppose we have to wait for a resolution to the problem (even if it's starting to take a long time after 2 weeks now...).
Yes, so in my opinion, my problem won't be solved since this is what happens in my case when the user leaves their docking station (connected via a network cable) and therefore switches to Wi-Fi to go to the meeting room...
I suppose we have to wait for a resolution to the problem (even if it's starting to take a long time after 2 weeks now...).
Indeed. I restarted the service and it reconnected, then I reconnected the network cable, and it disconnected again.
So it's not completely resolved.
Yes, it's starting to take a long time. There's a slight improvement.
Next test(s) in the build(s).
So it's not completely resolved.
Yes, it's starting to take a long time. There's a slight improvement.
Next test(s) in the build(s).
-
Christophe0110
- Messages: 53
- Registration: June 11, 2019 - 12:04
Thanks for your help, jc35.
Hopefully, this problem will be resolved quickly by the WAPT Team...
In the meantime, I created a small batch file that allows me to remotely restart the WAPT services for each machine displaying "DISCONNECTED"...
But it's a pain.
Hopefully, this problem will be resolved quickly by the WAPT Team...
In the meantime, I created a small batch file that allows me to remotely restart the WAPT services for each machine displaying "DISCONNECTED"...
But it's a pain.
Hello everyone,
I have a Debian 10 VM with Wapt 2.1.10550.
I'm experiencing the same problem as you,
namely disconnected workstations.
I also have another problem with OUs: an error value = -1 when attempting to edit the packet for this OU.
Jean-Philippe.
I have a Debian 10 VM with Wapt 2.1.10550.
I'm experiencing the same problem as you,
namely disconnected workstations.
I also have another problem with OUs: an error value = -1 when attempting to edit the packet for this OU.
Jean-Philippe.
-
Christophe0110
- Messages: 53
- Registration: June 11, 2019 - 12:04
I see there are new nightly builds since jc35's test.
Personally, I don't feel like testing them...
Is there somewhere we can see the changes and fixes included in these nightly builds?
For example, in this release version changelog:
https://www.wapt.fr/fr/doc/wapt-changelog.html
Cheers!
Personally, I don't feel like testing them...
Is there somewhere we can see the changes and fixes included in these nightly builds?
For example, in this release version changelog:
https://www.wapt.fr/fr/doc/wapt-changelog.html
Cheers!
- sfonteneau
- WAPT Expert
- Messages: 2318
- Registered: July 10, 2014 - 11:52 PM
- Contact :
Hello,
indeed we wanted to limit database access using WebSockets, but this is clearly causing problems.
Overall, we have an issue with the WebSocket library we're using.
While waiting for a patch (which should arrive shortly), you can use the "Tools->Reset WebSocket Connections" button in the console. This will reset the connection on the machines selected in the grid.
This forces the machines to reconnect.
We've identified a second potential problem: by default, the WAPT agent restarts automatically every day (24 hours).
To do this, we use a scheduled task that runs `net stop waptservice` and `net start waptservice`. This scheduled task is created automatically if the service has been running for more than 24 hours. It seems that sometimes the stop command fails, and the start command doesn't follow. The service therefore remains stopped.
We'd need to determine if you're experiencing the first or second scenario.
- Simon
indeed we wanted to limit database access using WebSockets, but this is clearly causing problems.
Overall, we have an issue with the WebSocket library we're using.
While waiting for a patch (which should arrive shortly), you can use the "Tools->Reset WebSocket Connections" button in the console. This will reset the connection on the machines selected in the grid.
This forces the machines to reconnect.
We've identified a second potential problem: by default, the WAPT agent restarts automatically every day (24 hours).
To do this, we use a scheduled task that runs `net stop waptservice` and `net start waptservice`. This scheduled task is created automatically if the service has been running for more than 24 hours. It seems that sometimes the stop command fails, and the start command doesn't follow. The service therefore remains stopped.
We'd need to determine if you're experiencing the first or second scenario.
- Simon
Hello,
I have exactly the same problem with about a third of our deployed machines.
The error logs are almost always the same:
CRITICAL Error merging
Packages from wapt into db: None: None
CRITICAL Error merging Packages from wapt-host into db: None: None
WARNING Websocket connect params: HTTPSConnectionPool(host='wapt.XXX.fr', port=443): Max retries exceeded with url: /get_websocket_auth_token (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
WARNING Websocket connect params: Unable to get auth token: Error on server:
EWaptAuthenticationFailure('Unknown host UUID XXXXX. Please register first.')
I am currently on the latest version of the WAPT agent, 2.1.
Sincerely,
I have exactly the same problem with about a third of our deployed machines.
The error logs are almost always the same:
CRITICAL Error merging
Packages from wapt into db: None: None
CRITICAL Error merging Packages from wapt-host into db: None: None
WARNING Websocket connect params: HTTPSConnectionPool(host='wapt.XXX.fr', port=443): Max retries exceeded with url: /get_websocket_auth_token (Caused by NewConnectionError(': Failed to establish a new connection: [Errno 11001] getaddrinfo failed'))
WARNING Websocket connect params: Unable to get auth token: Error on server:
EWaptAuthenticationFailure('Unknown host UUID XXXXX. Please register first.')
I am currently on the latest version of the WAPT agent, 2.1.
Sincerely,
-
Christophe0110
- Messages: 53
- Registration: June 11, 2019 - 12:04
Good morning,sfonteneau wrote: ↑Nov 2, 2021 - 11:37 AM Hello,
Indeed, we wanted to limit database access using WebSockets, but this is clearly causing problems.
Overall, we have an issue with the WebSocket library we're using.
While waiting for a patch (which should arrive soon), you can use the "Tools->Reset WebSocket Connections" button in the console. This will reset the connection on the machines selected in the grid.
This forces the machines to reconnect.
We've identified a second potential problem: by default, the WAPT agent restarts automatically every day (24 hours).
To do this, we use a scheduled task that runs `net stop waptservice` and `net start waptservice`. This scheduled task is created automatically if the service has been running for more than 24 hours. It seems that sometimes the stop fails and the start fails. The service therefore remains stopped.
We'd need to see if you're experiencing the first or second scenario.
Simon
I could be in both cases but in my opinion, I am more in the first case because the positions concerned are mostly laptops (so they do not stay on for 24 hours, in theory).
But I'll test the button in the console; it'll help me while I wait for a fix...
Christophe.
