Bug 1424605

Summary:	x11vnc-0.9.13-11.el7 fails with Connection reset by peer
Product:	[Fedora] Fedora EPEL	Reporter:	Jay Hilliard <jay.hilliard>
Component:	x11vnc	Assignee:	Petr Pisar <ppisar>
Status:	CLOSED EOL	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	epel7	CC:	pahan
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2024-07-08 22:28:48 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jay Hilliard 2017-02-17 18:56:30 UTC

Description of problem:
x11vnc/vncviewer fails due to ipv6 issue

Version-Release number of selected component (if applicable):

How reproducible:
Always

Steps to Reproduce:
ssh -X to a host with x11vnc 0.9.13-11 and rhost+ on Display :0
Run this command to view the desktop
x11vnc -display :0 -rfbport 5999 -auth ~/.Xauthority -repeat -noncache -noxdamage -q -bg ; vncviewer :99 &

Actual results:
 CConn:       connected to host localhost port 5999
 CConn:       read: Connection reset by peer (104)


Expected results:
  See/control my desktop (mate-desktop in this case)

Additional info:

To correct this, I am using two upstream packages I built on my RHEL7.1 system long ago:

x11vnc-0.9.14-2.el7.x86_64.rpm
libvncserver-0.9.10-5.el7.x86_64.rpm

I believe the issue is related to an ipv6 bug in libvncserver. I know x11vnc is epel and libvncserver is RH. but perhaps we can figure out if this can be fixed in epel without bothering RH about libvncserver?  Or I can open a RH Issue tracker if we determine the problem must be fixed in libvncsever?  Thanks in advance! And just a note that we use Nvidia drivers (from Negativo), but should not be related.

Comment 1 Fedora Admin XMLRPC Client 2020-04-06 19:34:28 UTC

This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 2 Petr Pisar 2020-04-07 09:10:30 UTC

I cannot reproduce it. I have x11vnc-0.9.13-11.el7.x86_64, libvncserver-0.9.9-14.el7_7.x86_64 and vncviewer from tigervnc-1.8.0-19.el7.x86_64.

Do I under stand correctly that you have RHEL system with running X server on display :0, then you connect there with SSH, start x11vnc to serve the :0 display on RFB 5999 TCP port, then you start vncviewer to connect to that x11vnc server and display an X window on default X display that is the SSH-tunneled display of you SSH client?

I used Xvfb as a server for my :0 display on a RHEL system, I started x11vnc, it started to list on IPv6 socket, then I used vncviewer to connect there and display on the same :0 display (instead of you forwarding it via SSH). And all connctions were successful:

$ DISPLAY=:0 vncviewer :99

TigerVNC Viewer 64-bit v1.8.0
Built on: 2019-10-10 05:48
Copyright (C) 1999-2017 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Tue Apr  7 10:50:31 2020
 DecodeManager: Detected 4 CPU core(s)
 DecodeManager: Creating 4 decoder thread(s)
 CConn:       connected to host localhost port 5999
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 CConnection: Choosing security type None(1)
 DesktopWindow: Adjusting window size to avoid accidental full screen request
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding

x11vnc listens on IPv6 socket by default where it also accepts IPv4 connects:

$ DISPLAY=:0 vncviewer 127.0.0.1:99

TigerVNC Viewer 64-bit v1.8.0
Built on: 2019-10-10 05:48
Copyright (C) 1999-2017 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.

Tue Apr  7 11:05:26 2020
 DecodeManager: Detected 4 CPU core(s)
 DecodeManager: Creating 4 decoder thread(s)
 CConn:       connected to host 127.0.0.1 port 5999
 CConnection: Server supports RFB protocol version 3.8
 CConnection: Using RFB protocol version 3.8
 CConnection: Choosing security type None(1)
 DesktopWindow: Adjusting window size to avoid accidental full screen request
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using Tight encoding

and the server logs:

07/04/2020 11:05:26 Got connection from client 127.0.0.1
07/04/2020 11:05:26   other clients:
07/04/2020 11:05:26 Normal socket connection
07/04/2020 11:05:26 incr accepted_client=1 for 127.0.0.1:52340  sock=14

Your error message seems to come from the vncviewer and it seems to successfully connecting to the x11vnc server and then it receives a TCP error. It usually happens when a server closes the connection, the client does realize it and attempts to send a new data to the server. Then the server rejects the data with the Connection reset by peer TCP reset error message. It would be great to see a log from your x11vnc server.

Comment 3 Troy Dawson 2024-07-08 22:28:48 UTC

EPEL 7 entered end-of-life (EOL) status on 2024-06-30.\n\nEPEL 7 is no longer maintained, which means that it\nwill not receive any further security or bug fix updates.\n As a result we are closing this bug.

Comment 4 Red Hat Bugzilla 2024-11-06 04:25:04 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days