Bug 131354 - vino not working with system updated from fc2 to fc3t1 via yum
vino not working with system updated from fc2 to fc3t1 via yum
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: vino (Show other bugs)
3
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Mark McLoughlin
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-31 10:09 EDT by Thomas J. Baker
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version: 2.7.92-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-01 03:01:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
typescript of strace of vino-server (58.25 KB, application/octet-stream)
2004-08-31 10:11 EDT, Thomas J. Baker
no flags Details

  None (edit)
Description Thomas J. Baker 2004-08-31 10:09:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040803 Galeon/1.3.17

Description of problem:
Katratzi is a SMP p3/1GHz that has been yum upgraded from FC2 to
rawhide. Doolittle is an Athlon 1.4GHz that had FC3T1 installed from
scratch. Wintermute is an SMP Xeon/3GHz that is running FC2 and the
rebuilt-for-fc2 rawhide vino rpm.

I can't connect to katratzi with remote desktop enabled. The vnc
connection from any system just hangs. I've tried with password
authentication, dialog confirmation, and no authentication and nothing
works. The same problem occurs with wintermute. Doolittle works fine
in any configuration. 

I'll next include an strace of vino-server during a connection from
wintermute to katratzi. I eventually interrupted the strace as it was
just repeating endlessly.

Version-Release number of selected component (if applicable):
vino-2.7.91-1

How reproducible:
Always

Steps to Reproduce:
1. yum upgrade from fc2 to rawhide
2. configure vino
3. try to connect
    

Actual Results:  vncviewer from a client just hangs.

Expected Results:  vncviewer show remote desktop.

Additional info:
Comment 1 Thomas J. Baker 2004-08-31 10:11:43 EDT
Created attachment 103291 [details]
typescript of strace of vino-server
Comment 2 Mark McLoughlin 2004-08-31 10:49:42 EDT
Could you run this from the client side:

  $> vncviewer -Log *:stderr:100 katratzi
Comment 3 Thomas J. Baker 2004-08-31 11:07:43 EDT
wintermute> vncviewer -Log \*:stderr:100 katratzi:0
 
VNC viewer for X version 4.0 - built Aug 27 2004 16:16:52
Copyright (C) 2002-2004 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
 
Tue Aug 31 11:07:29 2004
 CConn:       connected to host katratzi port 5900
 CConnection: reading protocol version
 CConnection: Server supports RFB protocol version 3.7
 CConnection: Using RFB protocol version 3.7
 CConnection: processing security types message
 


just hangs there

connecting to doolittle from wintermute works with the following output:

wintermute> vncviewer -Log \*:stderr:100 doolittle:0
 
VNC viewer for X version 4.0 - built Aug 27 2004 16:16:52
Copyright (C) 2002-2004 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
 
Tue Aug 31 11:09:01 2004
 CConn:       connected to host doolittle port 5900
 CConnection: reading protocol version
 CConnection: Server supports RFB protocol version 3.7
 CConnection: Using RFB protocol version 3.7
 
Tue Aug 31 11:09:02 2004
 CConnection: processing security types message
 CConnection: Server offers security type VncAuth(2)
 CConnection: Choosing security type VncAuth(2)
 CConnection: processing security message
 
Tue Aug 31 11:09:13 2004
 CConnection: processing security result message
 CConnection: processing security result message
 CConnection: Authentication success!
 CConnection: reading server initialisation
 CConnection: initialisation done
 TXImage:     Using shared memory XImage
 TXImage:     Using default colormap and visual, TrueColor, depth 24.
 CConn:       Using pixel format depth 6 (8bpp) rgb222
 CConn:       Using ZRLE encoding
 DesktopWindow: selection (1) time is 1192258751, later 1
 DesktopWindow: no selection (349)
 DesktopWindow: selection (1) time is 1192258751, later 0
 DesktopWindow: no selection (349)
 DesktopWindow: cut buffer time is 0, later 0
 
Tue Aug 31 11:09:14 2004
 CConn:       Throughput 4000 kbit/s - changing to hextile encoding
 CConn:       Throughput 4000 kbit/s - changing to full colour
 CConn:       Using pixel format depth 24 (32bpp) little-endian rgb888
 CConn:       Using hextile encoding
 
Tue Aug 31 11:09:31 2004
 DesktopWindow: selection (1) time is 1192258751, later 0
 DesktopWindow: no selection (349)
 DesktopWindow: cut buffer time is 0, later 0
 DesktopWindow: selection (1) time is 1192258751, later 0
 DesktopWindow: no selection (349)
 DesktopWindow: cut buffer time is 0, later 0
 

Comment 4 Mark McLoughlin 2004-08-31 11:10:15 EDT
Yeah, just what I thought from looking at the stack trace:

write(2, "31/08/2004 09:43:13 AM ", 2331/08/2004 09:43:13 AM ) = 23
write(2, "Protocol version 3.7\n", 21Protocol version 3.7
)  = 21
write(16, "\0", 1)                      = 1

The server is returning zero security types. wtf?
Comment 5 Mark McLoughlin 2004-08-31 11:31:09 EDT
gconftool-2 -g /desktop/gnome/remote_access/require_encryption ?
Comment 6 Mark McLoughlin 2004-08-31 12:26:09 EDT
Okay, I have a patch - will build soon
Comment 7 Thomas J. Baker 2004-08-31 13:42:12 EDT
katratzi> gconftool-2 -g /desktop/gnome/remote_access/require_encryption
true
katratzi>


Is this no longer supported(?) option messing me up? I remember it
used to be in the caplet but now it's gone.
Comment 8 Mark McLoughlin 2004-09-01 03:01:34 EDT
Fix will be in rawhide soon, thanks

* Wed Sep  1 2004 Mark McLoughlin <markmc@redhat.com> 2.7.92-2
- Add patch to fix hang without GNU TLS (bug #131354)

Note You need to log in before you can comment on or make changes to this bug.