Forum Replies Created
-
Posts
-
Hi, we have been investigating in the meantime (since you submitted the nxegl log) and we have a potential patch for the issue that you were encountering. If you are interested in testing a patched package, let us know 🙂
We’ve noticed from your dump that the wkscli DLL which is crashing when it accesses your WSL mount point is version 10.0.19041. You could evaluate updating your Windows machine to something more recent, since the latest Win10 is 10.0.19045.
Hi, we currently have a Trouble Report open on Bookworm for which the workaround is disable Wayland.
https://www.nomachine.com/TR10U11031.
However, our own tests have shown that it happens even when an HDMI screen is attached. So if possible, we would like to debug your device further. Before you try disabling Wayland, could you enable debug and gather some logs? We would need logs from a session to the Raspberry device as headless (no HDMI plugged), and then logs from a session with the screen attached, so one set of logs for each session. For instructions on how to enable debug and gather the logs, please check the instructions here: https://kb.nomachine.com/DT07S00243. Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
After a full analysis, we know the client fails to open because a system library raises an exception that causes the process to immediately close. When starting the machine in safe mode, the player has no problems so it means something loaded on the system (and not loaded in safe mode) is triggering the wkscli.dll exception.
While the dump is useful to understand, more or less, when the problem occurs, we didn’t find clear reasons to explain the issue in detail and offer an analysis about the exception, and about how it affects NoMachine.
The only hint we can give is to debug WSL (Windows Subsystem for Linux) and wkscli that is creating a pipe giving problems. Specifically, the exception seems to occur after the following error:
CreateFile: \\wsl.localhost\PIPE\wkssvc Result: BAD NETWORK NAME
The pipe is legit and usually created for the IPC over SMB calls, so maybe the problem is caused by a buggy library or Linux subsystem. Disabling WSL should be a way to stop creating the wsl.localhost mount point and verify if the player starts correctly.
Thanks for submitting them. Unfortunately the logs were incomplete. Please do the following:
1) make sure ‘SessionLogClean 0’ is set in /usr/NX/etc/node.cfg
2) restart nxserver
3) reproduce the problem
4) manually create an archive of the /home/base/.nx dir on the server
You don’t need to restart, the change will apply to any new virtual desktops. If there is no change when creating new virtual desktop sessions, it could be useful to see the journalctl after having applied the change to check what errors appear. But prior to that you should cleanup the gnome configuration in that specific user’s home.
Here is the link to the Trouble Report which you can monitor to know when the fix has been released.
Hi, an update on this. You sent us the logs and you also told us you were already using open source drivers. The logs show that the capture method fails with the same errors that we have seen when proprietary drivers are in use. Can you tell us more about the open source drivers you are using? And also confirm whether the server is running in a VM or not.
It might be. As I mentioned earlier, the issue is triggered by a strange case where all sockets get into an error state at the same time. This is for sure something occurring at the system level and not dependent on NoMachine. We don’t know the specific reason, but the point is that NoMachine doesn’t fail cleanly in this particular case and an infinite loop starts, spamming the log. We detected the problem and a fix will be available in the next release. If you want, we can send a patched library.
A fix will be available in the next release for mobile. Please use the following link to track its status: https://kb.nomachine.com/TR10V11229.
We have released an update so you should download the latest package for your architecture and try that. You can disable Wayland by doing the following:
sudo raspi-configAdvanced Options -> Wayland -> X11 -> OK -> Finish -> Yes (to reboot)If you are still encountering the issue, please submit the NoMachine logs from the Raspberry Pi device. You can extract them using the instructions here: https://kb.nomachine.com/DT07S00243
Send them to forum[at]nomachine[dot]com. Please use the title of this topic as the subject of your email. Thanks!
Is it possible you have a double NAT (if your IP address that you are using to connect does not match what is showing on whatismyip.com, it could be an indication of two routers)? UPnP doesn’t support the double NAT scenario, so you would need to enable port-forwarding on both routers.
At the moment there is no option on the client side BUT we are going to add a “disconnection option” in the player GUI to handle the situation when a session may become inactive. Similarly for the server side, we will also add an option to disconnect the connect in the GUI so that users can avoid interacting with the cfg files. We don’t have an ETA, but it’s definitely something we are going to do.
For your question about player.cfg options, take a look at the following document: https://kb.nomachine.com/DT07S00240.
Did you already take a look at the following article?
How to connect over the internet to NoMachine behind a NAT router
https://kb.nomachine.com/AR10R01099“Failed to map the port on gateway” suggests that the port you used in the port-forwarding rule on your router could already already be in use. Go back to your router and change the external port number to something else, then restart the nxserver (NoMachine settings -> Server -> Status -> Restart) . For safe measure also restart UPnP.
Is it possible there is a double NAT in place? If so, you will need to map the ports on both routers. So Router A must map to Router B and Router B to the computer you want to access.