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.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
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.
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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days