Error is 54: Connection reset by peer

[ferry]

Hello,

Client MacOS: 10.15.7 (Catalina) /11.5.2 (BigSur)  – NoMachine 7.6.2_free-version
Server : Ubuntu 20.04.2 LTS (Headless on VMware) – NoMachine 7.6.2_4_free-version (install via dpkg)

After working successfully for several months, now the connection gets reset by the server “Error is 54”. The error is shown after several connect attempts that all receive a reset.
This could be due to package updates done on the server. Removed the previous older NoMachine package and reinstalled it.
Same reset behavior.

Installed NoMachine on fresh Ubuntu 20.04.2 installed server, same reset issue. This does let me believe NoMachine is having issues with the latest update of Ubuntu 20.0.4.2. (with packet capture is do see server sends rst packet to client).

Enabled the server-side logging and discovered the following warnings

NXSERVER WARNING! Cannot check WM on display :1024 EEXIS
NXSERVER WARNING! Session F07FBB031CC440CAB7FACBDBC88D136B crashed on display 1024.
NXSERVER WARNING! nxclient –monitor cannot be started for session type loginwindow.

Attached is the server-side log archive file from the full debug.

Hope you can spot what changed and causes this issue.

Ferry

Attachments:

1. NoMachine-log-2021.08.19-18.38.03.zip

[Mth]

Hello,

From the logs, the login window seems to be running on Wayland.
Since the machine is virtual this may be a problem for our standard capturing method.

Our agent reports this exact problem:

848098 848124 18:36:58 426.520 WaylandPoller: ERROR! Grabber init failed.
848098 848124 18:36:58 426.530 WaylandPoller: ERROR! Grabber creation failed.
848098 848124 18:36:58 426.533 WaylandPoller: ERROR! Init failed.

The fix for this would be either disabling the Wayland from both desktop manager (gdm) and desktop itself, or if you wish to keep Wayland please follow our article about this problem:

https://knowledgebase.nomachine.com/AR04R01083

I am not sure why it has suddenly become a problem after update, but it was either that Wayland was previously disabled and enabled by default on update, or our fix was overwritten by updated files: the egl-capture function provided in the article modifies desktop manager config file, so any update would most likely break it again.

Please let us know if this works, or if you have any other questions.

/Mth

[ferry]

Hello Mth,

I found that article yesterday evening late and tried option 1.
I confirm that after applying option 2 (and reboot as systemctl/restart didn’t work) screen sharing works access again!

Thanks a lot (and feel pitty I didn’t tried #2 before),
Ferry

[Author]

Posts