GNOME Bugzilla – Bug 490428
Can not connect vnc server
Last modified: 2009-02-26 12:52:33 UTC
Build trunk code on Solaris, 1) start vinagre 2) Clickt "Connect" 3) Input a hostname like "rebound" in Host filed Expected result: Open a VNC view of the VNC server Actual result: Connction to host "rebound:5900" was closed. vncviewer can access rebound:5900 at the same time.
Hi, Halton. Have you used the versions (both vinagre and gtk-vnc) from trunk? Could you build gtk-vnc with the option --enable-debug and start vinagre in a terminal? Paste here the output please. What is the server running in "rebound"? Thanks.
Yes, I build gtk-vnc and vinagre both from trunk, and rebound is running vino. As your request, paste the log here(I'm using another box called judo). $vinagre Started background coroutine Resolving host judo 5900 Trying socket 17 Doing final VNC cleanup Requesting that VNC close Requesting that VNC close Releasing VNC widget
That log suggests it is failing to connect() to the remote host. Can you run 'strace -o vinagre.log -s 4000 vinagre' and attach the resulting vinagre.log. This should hopefully show exactly what system call is failing & why.
strace does not give me what I want. $strace -o vinagre.log -s 4000 vinagre ERROR: unable to open /dev/log Any other way?
Halton, in Solaris, you could use truss to see the system calls.
Created attachment 98154 [details] turss result of vinagre This is truss log of vinagre, please check.
At first time we connect, we get EINPROGRESS, the second time, we get EISCONN. Any clue here, Dan? (/me is not so familiar with network programming as he wanted)
The first time we get EINPROGRESS it means the OS is blocking waiting for the connection to complete. So we go into the GTK poll loop, when the FD indicates writable, it means the connection has completed. In this code we then do mistakenly do connect() again, but reading the man page, what we should be doing is: [quote] After select(2) indicates writability, use getsockopt(2) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure). [/quote] So looks like I need to fix this up - at the very least treat EISCONN as a success, but really the correct thing todo is the getsockopt() stuff
(In reply to comment #8) > So looks like I need to fix this up - at the very least treat EISCONN as a > success, but really the correct thing todo is the getsockopt() stuff Ok, i did the easiest thing: consider EISCONN as a success :)