starred/webvirtmgr

Fork 0

mirror of https://github.com/retspen/webvirtmgr.git synced 2026-04-26 08:05:54 +03:00

[GH-ISSUE #558] VNC fails after a few seconds of working #420

New issue

Open

opened 2026-02-27 16:39:14 +03:00 by kerem · 7 comments

kerem commented

2026-02-27 16:39:14 +03:00

Owner

Originally created by @lahdekorpi on GitHub (May 21, 2015).
Original GitHub issue: https://github.com/retspen/webvirtmgr/issues/558

VNC works at first perfectly but after a few seconds of being connected, the log outputs this:

==> /var/log/supervisor/webvirtmgr-console.log <==
  5: 88.195.6.57: Plain non-SSL (ws://) WebSocket connection
  5: 88.195.6.57: Version hybi-13, base64: 'False'
  5: Try to open tunnel on webvirtmgr@10.0.0.1:3000 on console 127.0.0.1:5900 (or socket None)
  5: Tunnel openned
  5: Start proxying
  5: handler exception: (4, 'Interrupted system call')

And I get a disconnect in the browser: "Server disconnected (code: 1006)".
After refreshing the browser window, everything works again for a few seconds.

Any ideas?

I'm behind a NAT and doing this:

iptables -t nat -I PREROUTING -p tcp -d {public_ip} --dport 6080 -j DNAT --to-destination 10.0.1.5:6080

Is this something that might affect it?

Originally created by @lahdekorpi on GitHub (May 21, 2015). Original GitHub issue: https://github.com/retspen/webvirtmgr/issues/558 VNC works at first perfectly but after a few seconds of being connected, the log outputs this: ``` ==> /var/log/supervisor/webvirtmgr-console.log <== 5: 88.195.6.57: Plain non-SSL (ws://) WebSocket connection 5: 88.195.6.57: Version hybi-13, base64: 'False' 5: Try to open tunnel on webvirtmgr@10.0.0.1:3000 on console 127.0.0.1:5900 (or socket None) 5: Tunnel openned 5: Start proxying 5: handler exception: (4, 'Interrupted system call') ``` And I get a disconnect in the browser: "Server disconnected (code: 1006)". After refreshing the browser window, everything works again for a few seconds. Any ideas? I'm behind a NAT and doing this: ``` iptables -t nat -I PREROUTING -p tcp -d {public_ip} --dport 6080 -j DNAT --to-destination 10.0.1.5:6080 ``` Is this something that might affect it?

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@Hyllegaard commented on GitHub (Jun 9, 2015):

Hi.

I am seeing the same thing. I am not behind NAT so that should be ruled out :)
However it appear only to happen if there is no input for a few seconds.

Regards

Jens

@Hyllegaard commented on GitHub (Jun 9, 2015): Hi. I am seeing the same thing. I am not behind NAT so that should be ruled out :) However it appear only to happen if there is no input for a few seconds. Regards Jens

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@kaystrobach commented on GitHub (Jun 15, 2015):

maybe related #561 ?

@kaystrobach commented on GitHub (Jun 15, 2015): maybe related #561 ?

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@lahdekorpi commented on GitHub (Jun 15, 2015):

Automatic reconnect would be a nice feature, but that doesn't really fix the root cause.
It is disconnecting even if the machine isn't rebooting, etc.
And in my case it disconnects randomly even when typing input.

@lahdekorpi commented on GitHub (Jun 15, 2015): Automatic reconnect would be a nice feature, but that doesn't really fix the root cause. It is disconnecting even if the machine isn't rebooting, etc. And in my case it disconnects randomly even when typing input.

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@kaystrobach commented on GitHub (Jun 15, 2015):

mhmm also had this :(

@kaystrobach commented on GitHub (Jun 15, 2015): mhmm also had this :(

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@howels commented on GitHub (Aug 14, 2015):

Same here also, any ideas for a fix?

Edit: seems to be fixed in websockify 0.7.0. Will try to upgrade via pip.

Yup, fixed with websockify upgrade (sudo pip install --upgrade websockify) but seems to break direct TCP connections, it's only working for SSH. Not really a problem.

@howels commented on GitHub (Aug 14, 2015): Same here also, any ideas for a fix? Edit: seems to be fixed in websockify 0.7.0. Will try to upgrade via pip. Yup, fixed with websockify upgrade (sudo pip install --upgrade websockify) but seems to break direct TCP connections, it's only working for SSH. Not really a problem.

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@it-community commented on GitHub (Nov 9, 2015):

Hello
I had the same problem, my connection name was server-kvm, and i ve the problem with the console (vnc or spice). I delete my server "server-kvm", and i recreate it with the name "server" and now the problem is solve

@it-community commented on GitHub (Nov 9, 2015): Hello I had the same problem, my connection name was server-kvm, and i ve the problem with the console (vnc or spice). I delete my server "server-kvm", and i recreate it with the name "server" and now the problem is solve

kerem commented

2026-02-27 16:39:14 +03:00

Author

Owner

@sf32738 commented on GitHub (Jun 10, 2016):

I was having the same issue. Further research and I ran across this noVNC issue.
https://github.com/kanaka/noVNC/issues/238#issuecomment-24316499

Updated the rfb.js configuration file to the following:

case 'connect':
        connTimer = setTimeout(function () {
                fail("Connect timeout");
            }, conf.connectTimeout * 5000);

        init_vars();
        connect();

        // WebSocket.onopen transitions to 'ProtocolVersion'
        break;

Once updates, I restarted the supervisor service and refreshed my browser. Issue appears to have gone away. --- still watching / testing.

update: 30min on an idle noVNC console session has not disconnected after changing the timeout value.

@sf32738 commented on GitHub (Jun 10, 2016): I was having the same issue. Further research and I ran across this noVNC issue. https://github.com/kanaka/noVNC/issues/238#issuecomment-24316499 Updated the rfb.js configuration file to the following: ``` case 'connect': connTimer = setTimeout(function () { fail("Connect timeout"); }, conf.connectTimeout * 5000); init_vars(); connect(); // WebSocket.onopen transitions to 'ProtocolVersion' break; ``` Once updates, I restarted the supervisor service and refreshed my browser. Issue appears to have gone away. --- still watching / testing. update: 30min on an idle noVNC console session has not disconnected after changing the timeout value.