Bug 885101

Summary: Sometimes waiting time a bit long when remote-viewer connecting to a unreachable graphic server
Product: Red Hat Enterprise Linux 6 Reporter: Cui Lei <lcui>
Component: spice-gtkAssignee: Marc-Andre Lureau <marcandre.lureau>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.4CC: acathrow, cfergeau, cwei, dblechte, lnovich, marcandre.lureau, mjenner, mzhan, tzheng
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: spice-gtk-0.20-1.el6 Doc Type: Bug Fix
Doc Text:
Cause: Connecting to unreachable host. Consequence: Connection timeout error takes about 2 minutes. Fix: Timeout only after 10s of unreachable host. Result: spice-gtk no longer waits for 2 minutes before reporting an unreachable host error.
Story Points: ---
Clone Of:
: 979130 (view as bug list) Environment:
Last Closed: 2013-11-21 08:25:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 961452    
Bug Blocks:    

Description Cui Lei 2012-12-07 14:14:11 UTC
Description of problem:
When remote-viewer connecting to a unreachable graphic server, the waiting time longer than 60 seconds. No error message pop up in the period of time.
The waiting time should be shorter when connecting to a unreachable server.

This issue scenario happened after remote-viewer has connected a guest successfully.

Here is the detail:
#remote-viewer vnc://1.2.3.4:59000 --debug
** (remote-viewer:4225): DEBUG: Insert window 0 0x132c010
** (remote-viewer:4225): DEBUG: fullscreen display 0: 0
** (remote-viewer:4225): DEBUG: fullscreen display 0: 0
** (remote-viewer:4225): DEBUG: Opening display to vnc://1.2.3.4:59000
** (remote-viewer:4225): DEBUG: Guest vnc://1.2.3.4:59000 has a vnc display
** (remote-viewer:4225): DEBUG: After open connection callback fd=-1
** (remote-viewer:4225): DEBUG: Opening connection to display at vnc://1.2.3.4:59000
** (remote-viewer:4225): DEBUG: notebook show status 0x132d020
** (remote-viewer:4225): DEBUG: Disconnected
** (remote-viewer:4225): DEBUG: close vnc=0x136fb10
** (remote-viewer:4225): DEBUG: notebook show status 0x132d020
** (remote-viewer:4225): DEBUG: Guest vnc://1.2.3.4:59000 display has disconnected, shutting down
** (remote-viewer:4225): DEBUG: Disposing window 0x132c010

At the same time, use tcpdump catch the tcp packages:
remote-viewer try to establish a tcp connection for some times.
I think the timeout value is a bit long and not sutable.

02:03:26.678972 IP (tos 0x0, ttl 64, id 51684, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.5.215.34085 > 1.2.3.4.59000: Flags [S], cksum 0xb684 (correct), seq 3284721950, win 14600, options [mss 1460,sackOK,TS val 181741818 ecr 0,nop,wscale 7], length 0
02:03:27.678544 IP (tos 0x0, ttl 64, id 51685, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.5.215.34085 > 1.2.3.4.59000: Flags [S], cksum 0xb29c (correct), seq 3284721950, win 14600, options [mss 1460,sackOK,TS val 181742818 ecr 0,nop,wscale 7], length 0
02:03:29.678544 IP (tos 0x0, ttl 64, id 51686, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.5.215.34085 > 1.2.3.4.59000: Flags [S], cksum 0xaacc (correct), seq 3284721950, win 14600, options [mss 1460,sackOK,TS val 181744818 ecr 0,nop,wscale 7], length 0
02:03:33.678545 IP (tos 0x0, ttl 64, id 51687, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.5.215.34085 > 1.2.3.4.59000: Flags [S], cksum 0x9b2c (correct), seq 3284721950, win 14600, options [mss 1460,sackOK,TS val 181748818 ecr 0,nop,wscale 7], length 0
02:03:41.678549 IP (tos 0x0, ttl 64, id 51688, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.5.215.34085 > 1.2.3.4.59000: Flags [S], cksum 0x7bec (correct), seq 3284721950, win 14600, options [mss 1460,sackOK,TS val 181756818 ecr 0,nop,wscale 7], length 0
02:03:57.678547 IP (tos 0x0, ttl 64, id 51689, offset 0, flags [DF], proto TCP (6), length 60)
    10.66.5.215.34085 > 1.2.3.4.59000: Flags [S], cksum 0x3d6c (correct), seq 3284721950, win 14600, options [mss 1460,sackOK,TS val 181772818 ecr 0,nop,wscale 7], length 0





Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-17.el6
spice-gtk-0.14-5.el6
spice-server-0.12.0-7.el6
spice-vdagent-0.12.0-3.el6
usbredir-0.5.1-1.el6
libvirt-0.10.2-10.el6
qemu-kvm-0.12.1.2-2.335.el6.x86_64
kernel-2.6.32-342.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.Prepare a spice guest, remote-viewer could connect the guest successfully #remote-viewer vnc://127.0.0.1:5900
2.User remote-viewer connect to a unreachable server (such as 1.2.3.4:59000)
# remote-viewer vnc://1.2.3.4:59000 --debug
  
Actual results:
The waiting time is longer than 60 seconds.

Expected results:
The timeout value should not set 60 seconds, which make user wait for a bit long time.

Additional info:
This issue scenario happened after remote-viewer has connected a guest successfully.

Comment 3 Marc-Andre Lureau 2013-05-09 23:17:06 UTC
ack and assigned, apparently the right API to use for that is g_socket_set_timeout() (reset it once connected)

Comment 4 Marc-Andre Lureau 2013-05-13 17:42:32 UTC
Sent patches to both Spice:
http://lists.freedesktop.org/archives/spice-devel/2013-May/013408.html

and gtk-vnc:
https://bugzilla.gnome.org/show_bug.cgi?id=700240

Comment 8 Marc-Andre Lureau 2013-06-27 17:25:36 UTC
fixed in spice-gtk-0.20-1.el6

Comment 14 errata-xmlrpc 2013-11-21 08:25:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1577.html