I am trying to run VNC server on a standard OpenSUSE 11.2 Gnome Desktop installation.I have done this succesfully with SLES for sometime, however, my experience with OpenSUSE 11.2 is that it doesn’t work out of the box!!
I am using XP Pro VNC viewer Free Edition 4.1.2
to connect.
I have removed “localhost” from the # special IPv6 addresses in hosts. This fixes the black screen issue for me.
All appears well until I disconnect and retry the connection after 5 minutes or so. Then VNC client makes the connection and then immediately disconnects. It’s a no go from then on.
If I reboot OpenSUSE 11.2 it works again but then reconnect fails again after the same period of time.
I am trying NX now as an alternative. However, I would much prefer to use VNC.
A silly question, but do you have the appropriate software on the server ? For example the way I use vnc / tightvnc requires that the Linux PC to which I am connecting have x11vnc installed, otherwise I get an immediate disconnect.
IMHO if one is not trying to train the person on the other end, then “nx” is FAR superior to “vnc”. BUT if one wishes to train the person on the other PC (so they can see exactly what you are doing on the desktop) then vnc is useful.
Hello oldcpu,
Thanks for the speedy response…
xllvnc is installed. Initially it all works as it should, I then disconnect. Then say 5 minutes later when I try to connect it succeeds then immediately disconnects. Thats it until I reboot the OpenSUSE 11.2 host. If on reboot, I do not connect within a few minutes of the boot when I attempt to connect it will disconnect the VNC client immediately. So it appears to me that something occurs during those few minutes after boot that changes the VNC system. My OpenSUSE 11.2 build is totally vanilla, gnome desktop, fixed IP address, fully patched up to date. Nothing added or any other settings changed. I have tried a fresh download of OpenSUSE 11.2 and used an OpenSUSE 11.2 simple appliance build from Suse Studio with the same results. I would like to find the problem and try to get it fixed. I don’t have a clue where to look for any logs or error messages.
where “remotepc-ip-address” is the ip address of your remote PC (fill in the ip address there), and in this example replace username with the proper username.
Of course have the appropriate 5900 and 22 ports open.
The above is fairly secure as it will “pipe” (is that the right word ?? ) the vnc connection over the encrypted ssh. If that works, then we know the problem is not with the basic vnc but rather lies in the front end software you are using.
I’m well down the road to using NX, however, I don’t like to leave something unresolved. I will fire up my OpenSUSE 11.2 netbook and try the vnc client on that. I hadn’t thought that it could be client related. I’ll try your suggestion also.
I use the tightVNC client to address tightVNC servers, from here: TightVNC: VNC-Compatible Free Remote Control Software
I don’t know if the realVNC client you are using is tuned to tightVNC servers. Maybe that will help?
Thx for this trick, I wasn’t aware till now that it was possible to access directly to the X11 server this way!!! Works fine on my MacBook with a terminal and JollyFastVNC.
But, the initial problem remains. Due to many other posts on the subject, it seems that there is something glitchy in the 11.2 with vncserver… The ssh trick shows me that my X11 server is responding, and that there is still a problem in the chain between services → xinetd → xvnc → x11.
So far, I’ve done these points:
corrected the /etc/hosts file to have localhost ipv4-localhost on 127.0.0.1;
suppressed localhost on the ipv6 line;
disabled ipv6 in network preferences;
corrected the /etc/xinetd.d/vnc file to modify localhost with ipv4-localhost;
check if the package x11vnc was installed or not, it is.
Thus, it still cannot connect to the VNC server: the client seems to immediately disconnect. I have no trace at all in messages or warn. As a matter of fact: how may I obtain some log from Xinetd to ensure that it actually receives requests? And that xinetd at least tries to launch Xvnc?
Thx to all for your different responses, they allow me to compile some tests and find out what’s wrong!
From a remote computer, a tcpdump shows me that the connection did traverse the router, the NAT and initiate something. So it’s not a network problem from router to ipv4 or ipv6 interpretation of the localhost.
The /var/log/xinetd.log confirms that connection is well done but last less than one second.
From the local net, a “vncviewer host_target:1” cmd shows that the VNC1 server was rejected with: Not a valid VNC server???
From the local net, a “vncviewer host_target:2” cmd shows that the VNC2 and VNC3 server was rejected with: Connection refused.
In /etc/xinetd.d/vnc, services VNC2 and VNC3 have a line “disable = yes”. That explain the “connection refused” messages.
Service VNC1 doesn’t have a line “disable = no”? Not sure if it’s necessary, so I put it back.
In /etc/xinetd.d/vnc, for all VNC servers, we have:
server_args = -noreset -SecurityTypes None -inetd -once -query localhost -geometry WWWWxHHH -depth 16
If the message received says “Not a valid server”, I guessed that something may be wrong with server_args… On Suse 10.3 (which works perfectly well, thx), there is no “-noreset” argument.
So, let’s have a try with these args (needs a “service xinetd restart”):
server_args = -SecurityTypes None -inetd -once -query localhost -geometry 1024x768 -depth 16
Doesn’t work better…
Starting the Xvnc on CLI with these args doesn’t work neither. It claims that “SecurityTypes” isn’t a correct arg???
So I try with these args:
server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
And TADA!!! Works!!! At least…
It seems that Xvnc binairies are no more the same between 10.3 and 11.2. Thanx guys to have updated binairies without testing if the config files need the same parameters…