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
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.
How can I go about finding what is going wrong?
<newbie with a little knowledge>
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.
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.
OK, then I am suspicous that vnc actually works, and its your front end software that you are using for vnc that is causing the problem.
To eliminate that possibility, connect instead with using basic terminal commands.
Do this is as follows. Type the following two commands, on two separate terminals both on your local PC, to remotely access your remote PC.
ssh -t -L 5900:localhost:5900 username@remotepc-ip-address 'x11vnc -localhost -nolookup -nopw -display :0'
vncviewer -encodings "tight copyrect hextile" localhost:0
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 still strongly recommend the “nomachine” program “nx”. NoMachine NX - Desktop Virtualization and Remote Access Management Software … but that is NOT a tightvnc method and hence it does not answer your question re: the method you want to employ.
I just realized my recommendation above will not work because you are doing this from winXP:
… sorry, in that case I can’t help. I have no experience in using winXP to connect to a Linux PC using VNC.
Instead I recommend (again) you use “nx”. If you not follow through this recommendation IMHO you are doing yourself a major disservice.
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.
Can you be more specific, I used your document when I had my problem. Is there a specific setting relating to Windows VNC client connectivity?
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?
It might be worth trying this on the server:
- Turn off vnc in xinetd.
- Turn on vnc by hand using the CLI with this command as ordinary user:
- connect from the client with this command
Doesn’t require any IPv6 or localhost manipulations from the defaults.
Easy to do, easy to reverse, might help, might not.
FFI: TightVNC Remote Desktop on openSUSE
I had the same problem with VNC and 11.2
corrected the /etc/hosts file to have localhost ipv4-localhost on 127.0.0.1;
edit the ipv6 line in /etc/hosts
::1 localhost ipv6-localhost ipv6-loopback
#::1 localhost ipv6-localhost ipv6-loopback
and it works
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…
Hope it’s help.