Raspberry Pi 5 RealVNC connects but not UltraVNC?

[jibun no kage]

Raspberry Pi 5 RealVNC connects and displays desktop fine, but not UltraVNC, I get a connection on port 5900, but then I get the following message from UltraVNC viewer "No supported authentication methods!"

Any assistance greatly appreciated!

[WDoc]

I have exactly the same problem with my new Raspberry pi 5, which I can access without any issue with RealVNC viewer from my Windows machine, but not with UNVC viewer (latest version). While UVNC viewer access works fine to access my Raspberry pi v.3.

The error message is the same as reported here above: "No supported authentication methods!"

Tried to change any possible parameter on UVNC viewer, yet no luck.

Would anyone have any idea maybe?

[Rudi De Vos]

Thanks to Vladimir Vissoultchev extra AUthentication methods have been implemented in the viewer.
binary test builds.
Please provide feedback
https://www.uvnc.eu/download/1440/vncvi ... .0-dev.zip

Extra Info
WIP: RSA-AES authentication and encryption (#139)

First cut of RSA-AES authentication and encryption
Fix AESEAXPlugin threading issues
Use separate DynBuffers for encoding and for decoding
Copy previous content when resizing DynBuffer
Remove CMAC and AES-EAX test vectors
On auth user cancel raise QuiteException
Allow multiple RestoreBuffer calls to gather enough incoming data
On ReadExact decryption plugin might need several lookahead peeks on
incoming data to fill encrypted buffer with enough data to be able
decrypt a chunk of plaintext enough to fulfil requested size of data
Repeat request is signalled by returning -1 from RestoreBuffer call
Various m_pDSMPlugin->IsEnabled() checks are added alternative m_pPluginInterface check
Stop using separate CSP context for client RSA key
Reduce memcpy on RestoreBuffer
Fix m_pPluginInterface availability check for RAW and Tight encoding
Allow CMAC to depend on externally initialized cipher
Add support for RSA-AES-256 security types
Use constant-time array compare and refactor err handling
Abstract client connection so RSAKEX can be reused for server-side impl
Remove user/pass spurious size checks
Add ClientConnectionRSAAES.cpp to vs2017 project
Show server identity confirmation dialog
Allow persisting server key fingerprint in options file
Fix non-encrypted RA2ne/RA2ne_256 sub-types encrypt til end of handshake
eNCrypt authentication with TLS encrypted transport (#142)

First cut VeNCrypt authentication with TLS encrypted transport
Add ClientConnectionTLS.cpp to vs2017 project
Cleanup includes
Fix TLS 1.3 support
Refactor member var names
Show warning dialog for invalid server certificates in TLS sub-types
Chain TLSVnc and X509Vnc sub-types to AuthVnc
Allow persisting TLS certificate thumbprint in options file

[WDoc]

Great, thanks a lot for the new soft version, seems to work for me now!

[jmh2024]

The issue is that the security types supported by default on RealVNC Server on the Pi does not include the legacy VNC authentication used by UltraVNC. Even if you change the RealVNC Server to use "VncAuth" you will still not get legacy support unless you check the “Allow connections from legacy VNC Viewer users” when entering the Server VNC password.

If you've already set VncAuth and a VNC Password without checking the legacy box, you can use the Expert options to change back to SystemAuth and click yes when asked to delete the saved password. Then switch back to VncAuth and a set password pop up will appear with the legacy option checkbox.

This worked for me using UltraVNC 1.4.3.6 viewer on Windows 10 and RealVNC 7.5.1 Server on a PI 2 running Raspian 11. You can verify the correct settings using wireshark to examine the "Security Types Supported" packet sent by the RealVNC server. If it does not include “Security Type: VNC (2)” then you'll get the no supported authentication methods error.

[grubi]

Thanks to Vladimir Vissoultchev extra AUthentication methods have been implemented in the viewer.
binary test builds.

Is it possible that this addition also solves the problem with new Intel ME/CSME Firmware now only supporting RFB3.8 over TLS which prevent UVNC to work any longer?

I have posted a related question here:

viewtopic.php?t=37980