Opensuse 13.2 VNC server problem

English Network/Internet
#1

Opensuse 13.2, fresh install. Configured VNC with Yast. Can not connect. “Conection closed” or whatever, depending on client, message. Not a client problem, tried Windows, Linux, Android clients, same problem. Any ideas?

http://s15.postimg.org/e91o3mpij/Screenshot_from_2015_04_21_20_49_00.png

#2

Add VNC to the Allowed Services in the YaST firewall configuration.
Howard

#3

Of course, it’s already done, from beginning.

#4

Is this VNC over a LAN (ie both PCs on same LAN) ? or is it with both PCs on different networks ? If different networks, do you have the routing setup properly ?

Are both PCs openSUSE (client and Server) ?

#5

No, PC’s are not in the same network, not even in same country at this time. Routing is done by TP-link router with OpenWRt on it… Ports are forwarded to server (5900, 5901, 5902, 5902). That can not be routing problem, because if ports would not be forwarded, or forwarded incorectly - client would not connect to server at all, not like here - disconnects after showing openSUSE background screen. (look at screenshot)
No, as i mentioned before - i tried lots of clients, Windows, Linux (Ubuntu), Android…

#6

On Wed, 22 Apr 2015 16:56:01 +0000, mendoza lt wrote:

> oldcpu;2706248 Wrote:
>> Is this VNC over a LAN (ie both PCs on same LAN) ? or is it with both
>> PCs on different networks ? If different networks, do you have the
>> routing setup properly ?
>>
>> Are both PCs openSUSE (client and Server) ?
>
>
> No, PC’s are not in the same network, not even in same country at this
> time. Routing is done by TP-link router with OpenWRt on it… Ports are
> forwarded to server (5900, 5901, 5902, 5902). That can not be routing
> problem, because if ports would not be forwarded, or forwarded
> incorectly - client would not connect to server at all, not like here -
> disconnects after showing openSUSE background screen. (look at
> screenshot)
> No, as i mentioned before - i tried lots of clients, Windows, Linux
> (Ubuntu), Android…

I wouldn’t do that. VNC security is nonexistent - no encryption of
traffic, and the passwords are easy to hack.

What I do (and suggest you do) is tunnel over ssh:

ssh -L 5910:localhost:5900 me@hostname

Then use vnc to connect to localhost:10

That should work just fine, regardless of firewall settings or anything
else - and it will keep you secure.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

#7

If you initially get the desktop and then it stops, are you certain it is openSUSE and not somewhere along the route that is stopping ? openSUSE worked initially from what you said. Why should openSUSE stop and not somewhere along the route ?

I agree a test with ssh, follows by a test of piping vnc through ssh is worth trying.

See post#13 in this thread: https://forums.opensuse.org/showthread.php/506746-remote-desktop-please-suggestions?p=2705127#post2705127

#8

Ok i tried, i did as in post #13, same problem. Connection closed.

I did:

ssh -t -L 5901:localhost:5901 root@myserver.bla 'x11vnc -localhost -nolookup -nopw -display :1'

and

 vncviewer -encodings "tight copyrect hextile" localhost:1

Then got a second long splashscreen of opensuse background (same as in screenshot in post #1)

and then this:



mendoza@mendoza-1000H:~$ vncviewer -encodings "tight copyrect hextile" localhost:1
Connected to RFB server, using protocol version 3.8
No authentication needed
Authentication successful
Desktop name "x11"
VNC server default format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor.  Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
vncviewer: VNC server closed connection
ShmCleanup called
#9

Have you tried any long term access tests to confirm the quality/consistency of the connect ?

Possibly try copying a file of reasonable size (not too small) to/from the PC, using say sftp, to see if the connection remains stable there over several minutes of sustained data access. Or if it is disconnected in such a case ?

Assuming tests show the connection is fine, possibly you can advise as to what vnc app versions you have ? For example, on my laptop (running openSUSE-13.2) that I use to access the desktop of my mother’s PC (over 7000km away) where she is running openSUSE-13.1 I use:


oldcpu@linux-0w6l:~> rpm -qa | grep vnc
tigervnc-1.4.1-6.29.1.x86_64
libvncclient0-0.9.9-10.2.1.x86_64
libvncserver0-0.9.9-10.2.1.x86_64
xorg-x11-Xvnc-1.4.1-6.29.1.x86_64

Further, please confirm you have no exotic defensive measures/scripts in place that will disconnect upon someone trying to hack, where that could have been triggered prematurely. Or if you do have such, disable it temporary, then try the vnc access to see if that temporary disabling makes a difference.

Is there any custom information about your vnc/remote connection that you have not told us that might help provide us further insight ?

You state you “Configured VNC with Yast” . I have never done such. I did not need to ‘configure’ yast other than to open the appropriate firewall ports. Vnc worked immediately out of the install (after my installing tigervnc (or tightvnc) and xorg-x11-Xvnc (and their associated dependencies).

#10

Yes, everything works perfect, just have successfully uploaded 800Mb size movie file.

myserver:~ #  rpm -qa | grep vnckdenetwork3-vnc-3.5.10-28.4.2.i586
libvncclient0-0.9.9-10.2.1.i586
xorg-x11-Xvnc-1.4.1-6.29.1.i586
tigervnc-1.4.1-6.29.1.i586
libvncserver0-0.9.9-10.2.1.i586
x11vnc-0.9.13-9.1.4.i586
x11vnc-frontend-0.9.13-9.1.4.i586

No, i don’t have any of these, or at least i don’t know anything about it, i did not enabled anything intentionally.

Nop, regular VNC…

Ah, yes, my bad - i should say “enabled VNC in Yast”, not “configured…”

#11

Do you really need the apps that I highlighed in red ? I don’t use them myself. Possibly one of them did something to a configuration file ? (I’m guessing here).

#12

Ok, i removed some, which i think is not needed…

myserver:~ # rpm -qa | grep vnc
libvncclient0-0.9.9-10.2.1.i586
xorg-x11-Xvnc-1.4.1-6.29.1.i586
tigervnc-1.4.1-6.29.1.i586
libvncserver0-0.9.9-10.2.1.i586
x11vnc-0.9.13-9.1.4.i586

I had to leave x11vnc, because it is needed here:

ssh -t -L 5901:localhost:5901 root@myserver.bla 'x11vnc -localhost -nolookup -nopw -display :1'

But, if your theory is right, then possibly even after removing them, configuration file could be not changed back…

#13

Now i’m thinking -

x11vnc-0.9.13-9.1.4.i586

and

xorg-x11-Xvnc-1.4.1-6.29.1.i586

are both vnc servers, and does more or less same thing, could it be that they are conflicting…?

#14

I believe x11vnc is required on the computer whose desktop you are taking over. It is not required on the other pc. But it should not cause a problem. xorg-x11-Xvnc I believe is required on both PCs (remote and local). I do not see the need for libvncserver0-0.9.9-10.2.1.i586. BUT having typed that, I did a test with without lbvncserver0 (my openSUSE-13.1 system) and with libvncserver0 installed (my openSUSE-13.2 system) and both worked fine.

I know you believe ports are not the issue, but have you tried other ports (such as the basic 5900 as opposed to 5901) ? Also localhost:0 instead of localhost:1 ? I have played a bit and thus far I can not replicate your problem. I do find thou that on my PCs, localhost:0 (ie with display 0) works better than 1.

#15

Some speculative ideas …

One thing I note is because I did not do anything special to configure vnc, I do not have any vnc config files (that I can find) in my regular user accounts. ie no ~/.vnc. Do you have such a directory ? If so you could try removing it and trying again (maybe back it up somewhere first, prior to removing).

I note my openSUSE-13.2 system has the file /etc/modprobe.d/10-libvnc.conf (where the contents are all commented out) while my openSUSE-13.1 system has no such file. Given both my 13.1 and 13.2 work for vnc, then from that I deduce that for vnc to nominally function without a special configuration, that file is not needed to be configured.

Is your remote system using XFCE (I’m not familiar with Gnome nor KDE) ? Is it possible something is configured wrong in that desktop ? I note for KDE I have a file /usr/share/kde4/services/vnc.protocol . I ask because I have the impression you used some sort of front end program to setup/use your VNC and that could have changed one or more configuration files, while I have always used the command line and hence I likely have a different configuration from yourself.

Has your /etc/xinetd.d/vnc file been altered since your PC’s original install ?

Hopefully this is something simple like the port or localhost/display causing a complication and not a configuration file issue.

Another thought is you could force a re-install on both remote and local PC of the specific applications we noted, in case one of them has been corrupted.

#16

But there’s no x11vnc in your server, and everything works fine?

#17

I always get the ‘server’ terminology confused in my head when it comes to X. Sometimes I think i am dyslexic.

One does not need the x11vnc app in one’s local PC, because one is running the x11vnc on the remote PC. ie I do not need x11vnc on my PC here in Europe when I take over the desktop of my mother’s PC in North America. However my mother’s PC in North America does need the x11vnc.

Still, my tests indicate having x11vnc on both PCs does not cause me a conflict.

#18
  1. I recommend tigervnc and not use tightvnc/YAST vnc setup. (Unfortunately, the rpm I used does not set up the correct /usr/bin/vncviewer, I have to make a symlink from tiger-vncviewer to vncviewer. So, after installing tigervnc, check that your /usr/bin/vncviewer is actually launching the tiger version.)
  2. Are you certain your ssh port forward statement is correct? I don’t know the ssh port forwarding syntax, but I think the original command proposed in this thread referenced 5910 and 5901. This may have been a typo or it may have been intended that vnc port 5901 be forwarded via ssh to 5910? I now use a VPN, but when I was port-forwarding, it seems to me ssh session was then on the default ssh port 22.
  3. A simple vncserver/vncviewer connection is pretty easy and I had problems when I tried to use the YAST vnc module and default tightvnc install. My tigervnc implementation: I run “vncserver” from terminal session on the server. It should respond by setting up a vncserver on the next available port. Eg., :1 or :2. (:0 is your display running on the server.) I then test via “vncviewer”, again on the server, and attach to “localhost:1”. You do have to set up the passwd file via vncpasswd, which by default will create ~/.vnc/passwd, but I assume you have done this or vncviewer would fail to authenticate. (Although, did I see “authentication not required” in your log file?) The vncserver will set up a default ~/.vnc/xstartup script which is designed to launch the same desktop you are running on the server, though by commenting out a few lines it will instead run xterm and the twm window manager (This can be changed – although I don’t know the command to run gnome. I like thinner remote sessions, so I change twm to icewm-session or startxfce. Probably startkde, startgnome or startx would work as well – I haven’t tried them.)
  4. After you can connect on localhost, avoiding network issues, then you can use vncviewer to [IP]:1 (or 2, or whatever). Although, I agree that if you are getting the screen to display in the first place, the issue is something else, not firewall or internet issues.
  5. Are you logging in as root? The normal vncserver setting is to block root logins. You would normally login as user and then su to root if you wish to perform root operations (assuming vncserver is set up to allow this, but that is the default.)
  6. I use neorouter (neorouter.com) to create a VPN.
  7. If you wish to access the running server desktop, run “x0vncserver --PasswordFile ~/.vnc/passwd” on the server and “vncviewer [IP]:0” on the client. (However, presumably your server is not running from a root login? Server should be running a user session …)
  8. You might try Remmina, as it does some of the work for you, I have had good luck with Remmina. (However, I like using the tigervnc vncserver and vncviewer, because the sessions can be re-sized by clicking the lower corner of the window, same as re-sizing any other window.)
#19
  1. I am using tigervnc

rpm -qa | grep vnc

libvncclient0-0.9.9-10.2.1.i586
remmina-plugin-vnc-1.0.0-11.2.1.i586
xorg-x11-Xvnc-1.4.1-6.29.1.i586
tigervnc-1.4.1-6.29.1.i586
libvncserver0-0.9.9-10.2.1.i586
x11vnc-0.9.13-9.1.4.i586

  1. That’s a typo

https://en.opensuse.org/SDB:VNC_usage

    1. i do not have a physical access to that server right now. I’m in different country now, I left it with a hope, that i will be able to connect to it via VNC from here… but now i do have only an SSH…

  2. I can not even access a login screen.

#20

I tried to reproduce. I had the same behaviour when trying to connect to :1 (5901) i.e. a non pre-existing X session.

I was able to take over an existing X session on a remote host by the following strategy:

On my local machine i entered as root:

ssh -l user -L1234:localhost:5900 my.remote.server.org

After logging on to the remote server, i typed manually as the user owning that X display:

x11vnc

on my local machine I entered in a second terminal as normal user:

vncviewer localhost:1234

So if you are trying to attach to an existing X session, this might the way to go.