Bug 885101 - Sometimes waiting time a bit long when remote-viewer connecting to a unreachable graphic server
Sometimes waiting time a bit long when remote-viewer connecting to a unreacha...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk (Show other bugs)
6.4
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Marc-Andre Lureau
Desktop QE
:
Depends On: 961452
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-07 09:14 EST by Cui Lei
Modified: 2014-11-09 17:24 EST (History)
9 users (show)

See Also:
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 03:25:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Cui Lei 2012-12-07 09:14:11 EST
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 19:17:06 EDT
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 13:42:32 EDT
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 13:25:36 EDT
fixed in spice-gtk-0.20-1.el6
Comment 14 errata-xmlrpc 2013-11-21 03:25:36 EST
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

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