Demo mode not working

[Fyroeo]

Hello,

I use Veyon for my class and it works like a charm, except for the demo mode.
I followed the guide here and everything is configured as it should.

My configuration is as follow:

• No access rules activated
• Auth keys in place for the connection
• Ports open into the Windows Firewall (the problem is also occurring on a Linux machine running the Veyon Master with no firewall in place)
• There is no any firewall into the network

Since the problem is occurring on Windows and Linux too, where could possibly be the error ?

Thanks to everyone that will help for my problem.

[andyvdg]

I have the same problem. But purely on Windows10 - haven't tried Linux yet.
Same setup - auth keys for authentication and verified ports are open and I can telnet without problems.
Master starts demo and all computers just display a black screen with "Connecting to master IP address".
One thing that is different in my configuration is that I am connecting to VMs using multi-session mode which works great for monitoring and remote control - master is the only computer not running via a different RDP session. Everything else seems to work but I cannot get this Demo mode working.

[andyvdg]

I've done some further testing.

Master = 10.10.0.2 (master is connected via VPN to virtual network)
Client = 10.10.2.4 (all clients are VMs in Azure Labs)
No firewalls in place
Windows firewall on both machines have been verified

Test if they can see each other

ping 10.10.2.4

Pinging 10.10.2.4 with 32 bytes of data:
Reply from 10.10.2.4: bytes=32 time=15ms TTL=128
Reply from 10.10.2.4: bytes=32 time=16ms TTL=128
Reply from 10.10.2.4: bytes=32 time=15ms TTL=128
Reply from 10.10.2.4: bytes=32 time=16ms TTL=128

Ping statistics for 10.10.2.4:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 16ms, Average = 15ms

ping 10.10.0.2

Pinging 10.10.0.2 with 32 bytes of data:
Reply from 10.10.0.2: bytes=32 time=15ms TTL=127
Reply from 10.10.0.2: bytes=32 time=15ms TTL=127
Reply from 10.10.0.2: bytes=32 time=16ms TTL=127
Reply from 10.10.0.2: bytes=32 time=15ms TTL=127

Ping statistics for 10.10.0.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 16ms, Average = 15ms

Service running on master and client

telnet localhost 11200

and I get the expected response on both

RFB 003.008

I can also see client machine in Veyon master and use all functionality without problem except for the demo mode.

Start Veyon Master app and start demo mode on master.
I would expect port 11400 to be open. But when I run

netstat -an | find "11400"

on the master machine it returns nothing.
And trying to telnet on master doesn't work either.

telnet localhost 11400
Connecting To localhost...Could not open connection to the host, on port 11400: Connect failed

From the client machine

netstat -an | find "11400"
  TCP    10.10.2.4:49956        10.10.0.2:11400        SYN_SENT

telnet 10.10.0.2 11400
Connecting To 10.10.0.2...Could not open connection to the host, on port 11400: Connect failed

I can find a few of these in my windows log but they don't always happen when I start Demo mode.

Faulting application name: veyon-server.exe, version: 4.3.3.0, time stamp: 0x00000000
Faulting module name: builtin-ultravnc-server.dll, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x0000000000036794
Faulting process ID: 0x59ac
Faulting application start time: 0x01d5f279aaa4b26f
Faulting application path: C:\Program Files\Veyon\veyon-server.exe
Faulting module path: C:\Program Files\Veyon\plugins\builtin-ultravnc-server.dll
Report ID: 1d029226-9acb-474b-b5da-7c0313941e60
Faulting package full name: 
Faulting package-relative application ID: 

[andyvdg]

Assuming it's a problem with the built-in VNC server malfunctioning I installed UltraVNC on my master machine.
Installed the service.
Configured password and started service.
Set Veyon to use External VNC server on port 5900 with the same password.

Et voila - it works now.
Somethings just not right with the built-in UltraVNC server.