I can connect to the SuSE 10.0 box with VNC if I use 192.168.43.50:2 and 192.168.43.50:5901 but if I try to connect with just 192.168.43.50 it will throw “Unable to connect to host: Connection Refused”.
Why won’t it connect with just the IP?
Maybe the default is :0? Maybe a designation is mandatory?
In any event, what’s wrong with designating the window (e.g. :1 etc)?
While some users wouldn’t mind specifying the display window via :2 or :5901 there are quite a few end users who will not remember to do this and the idle conditions of operation would be the server would then select an open display for them.
A designation never use to be mandatory and all of our other SuSE 10.0 deployments will connect right up and choose the next available display if you just specify the IP address. This is why I’m puzzled. This is a fresh installation of SuSE 10.0 so I’m not sure why when connecting by just the IP address would return connection refused. Could this be a config file issue or maybe a port forwarding problem? We have the firewall disabled on the box.
Any suggestions?
Hi there
Im pretty sure that the port number is mandatory. Ive tried this on 10.3 and up, and have found you always have to enter your ip address followed by “:[port number]” when connecting to the server. I assume this is because of the multiuser nature of unix (and by extension, linux). You could have an infinate number of vnc servers running on a single pc, each pointing a different user’s desktop (as far as i know, limited only by your hardware, available network ports, and bandwidth).
Each desktop is represented by a different port (by default, ports are in the 59xx range for the regular vnc server and in the 58xx range for http vnc servers–i.e. you can use a regular browser with java installed to view your desktop, without the need for a vnc viewer application). your vnc viewer application needs to know the desktop to which you are connecting, even if you are only running one instance of the vnc server.
anyone else have any thoughts because this can be a pain in the behind, especially if you are running only one vnc server at a time.
Which port would allow you to connect and see the main desktop? The one that is running on the system.
so you want to see the desktop that is displayed on your monitor at home (the way windows works VNC servers…)
thats a very good question…One I have been wondering for quite some time!
There has to be a way to do this…desktop sharing in the KDE control center perhaps? (if you are using KDE). Im on my way home soon, Ill look into it when I get home
. The zeroth (:0) windows server is alive and well. There are two VNC applications available on openSUSE (don’t know about Suse Linux 10.x). One is RPM:tightvnc which works in collaboration with RPM:xorg-x11-Xvnc and together they serve up XWindows :1, :2, :3 … etc. Then there’s RPM:x11vnc which serves up the zeroth window (the actual live running desktop). There are a few users on the Forums who talk about the :0 version (x11vnc), notably oldcpu.
ok
this isnt as painful as I thought it would be.
what you want to do IS POSSIBLE!
you need to first download and install the package “x11vnc” (its in the opensuse main repo)
It seems like a pretty complex program but the basic setup wasnt that bad…
you will need to set up a vnc password if you havent already done so. (invoke the command vncpasswd as the user who owns the desktop to which you will be connecting).
Then, issue the following command to start the server…
x11vnc -display:0 -usepw -forever
(substitute :0 with your display number, where applicable… unless you have any special display setups, like multiple X sessions, you should leave this as :0 )
if you enter the command as above in a terminal window, the server will run in that terminal window. If you close that terminal window with the server running, the server will shut down and any users who are connected will be disconnected. if you add an ampersand the character " & " after that command, it will fork the process into the background and you can safely close your terminal window.
i.e. x11vnc -display :0 -usepw -forever &
the -usepw option tells the server to use the vnc password authentication (set with the command vncpasswd) --optional but HIGHLY reccomended. The man page for x11vnc has several different methods of authenticating a user, this is the one that worked for me without much setup.
the -forever option tells the server to stay active even after you have closed the viewer application – this one is totally optional
then point your vncviewer to your remote pc followed by :0
(again, substitute :0 where needed – see above)
its a simple as that! let me know if this does what you need it to do
When attempting to connect with the :0 option it throws connection refused; however, it will let me connect on :! :2 :3 and so on. Why would it refuse connection on :0?
We have xorg-x11-Xvnc installed using kdm as the display manager. tightvnc is also installed; however, I’m not sure if it’s being used or not.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Because you are only listening on 590[12345] for VNC connections.
Typically you have two VNC options… the actual main display of the
box which by default listens on 5900 (and of which there is only one)
and all the other ones on 5901, 5902, 5903 which are created when you
connect to them and are never seen on the physical monitor (unless you
run the VNC client on the physical box displayed on the physical
monitor, of course).
Anyway, you’re using the normal one and not the other. The default (if
you don’t specify a display or port) is to use :0 or 5900 so when you
don’t specify it of course it does not work. You could setup something
like iptables/NetFilter (the firewall) to forward requests going to 5900
to another port like 5901 or 5902 or whatever if it helps your end
users. Look up port forwarding and iptables and similar on Google for a
lot of information on this. There have even been a few threads in these
forums recently on doing the same… it’s really simple to do and only
one command or so.
Good luck.
alanatdsi wrote:
> When attempting to connect with the :0 option it throws connection
> refused; however, it will let me connect on :! :2 :3 and so on. Why
> would it refuse connection on :0?
>
> swerdna Wrote:
>> . The zeroth (:0) windows server is alive and well. There are two VNC
>> applications available on openSUSE (don’t know about Suse Linux 10.x).
>> One is RPM:tightvnc which works in collaboration with RPM:xorg-x11-Xvnc
>> and together they serve up XWindows :1, :2, :3 … etc. Then there’s
>> RPM:x11vnc which serves up the zeroth window (the actual live running
>> desktop). There are a few users on the Forums who talk about the :0
>> version (x11vnc), notably oldcpu.
>
> We have xorg-x11-Xvnc installed using kdm as the display manager.
> tightvnc is also installed; however, I’m not sure if it’s being used or
> not.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIcBAEBAgAGBQJJmkS9AAoJEFl00+q2r0Yp+04P/AqHjCuIRJobWCkUdGlLvGqj
0ysgQ64TA0N4t17U2WF4AxO2YxgeY27ECHZTdU8AK1uN+0Ty1exrR953f4oXOuhb
HoUXi5+btbf6EFsUPqxka7laCmJ9Q2JSeQk3BmqbacujKKZmttDVrUxv+Qy8WyR3
6iORsatlF9wNNrMm8mBiuV8Su3XPE6WhSMrcYXaKZS2sAQ9ngr0mrm5YYwVT8ZfM
h+shMf+jJnNovYlj+8rrDbjY+5vQXyy0xqqyt9/SVDYoLvBdQscsSabK6ZQUfEom
5zwPyCEPs9qyePSdCvASKdRLi6kI5l6F7KphGpJ11ZfcWthHveE/HVloBkR3KfGZ
Mgf61EkrPmP0Si87J/od10kbxwM6e7+wnOiyVD+oUBKbyvYCB1mEmdvq0HrftQpr
285ihGxaKS5CXl7AB3eQZMZYqiGYKZvyMFIFxogjW8XFEjtdfCjUxXVRIJL0IdCC
gypKHYCrOTRCPdrJyfNpviDW2R/pVAiKF2fDKmkeRdNKXY2HqSZvHsOmD6esc9oS
GQJduxEHadFVPO6dO2tMKXQvLLEH8tK+W99wgjFjvMFAxFzn3+GESGHaGv74IhsV
1FSpIMZwSD5jJ0SgOfC0SElBmZtqmOsZnr5tEFhYXq2WDczelOLf9oOoFXxgjwKD
4RAucr64WmFKSkaovvkp
=cVkz
-----END PGP SIGNATURE-----
After hours of look at configuration files we ultimately found the culprit and I figured I’d share the reason as to why :0 would not work but :1 :2 :3 etc would.
My co-worker realized that the failure was that the VNC connection was being refused while the kdm ones on :2 worked as expected. So we went to another machine with working :0 and did…
find /etc/X11 -type f | xargs grep -l vnc
To find /etc/X11/xorg.conf contained vnc on the working box and none on the broken one.
We opened that file on the good box and found…
Load "vnc"
in the Modules section of the good one but not the failing one.
We added that line as the first module and requested a reboot. All is working now.
This is on a SuSE 10.0 box running x11-vnc with kdm.