Bug 856772 - vino-server doesn't listen on ports properly when switching to alternative port
Summary: vino-server doesn't listen on ports properly when switching to alternative port
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: vino
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Søren Sandmann Pedersen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-09-12 19:00 UTC by Jonathan Kamens
Modified: 2014-06-18 09:15 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-07-09 20:46:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
patch to fix bug (4.33 KB, patch)
2012-09-12 19:00 UTC, Jonathan Kamens
no flags Details | Diff
jonathan's patch updated to vino-3.6.2 (4.61 KB, patch)
2013-02-20 02:41 UTC, David Mansfield
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
GNOME Bugzilla 668187 0 None None None 2012-09-12 19:05:34 UTC

Description Jonathan Kamens 2012-09-12 19:00:09 UTC
Created attachment 612220 [details]
patch to fix bug

I have the tigervnc "vnc" X server module loaded and configured to listen for VNC connections on port 5900. I want to have vino-server listening on port 5901 at the same time. I therefore have use_alternative_port enabled in Vino's gsettings and the port number set to 5901.

When vino-server starts up, it starts listening on port 5901 like it should, but nothing happens when I connect a client to that port. Here's why (with a patch!)...

The "vnc" X server module is only listening on IPv4. Vino-server attempts to bind to both IPv4 and Ipv6 on port 5900. The latter works, but the former does not, so vino-server considers that "successful".

Then, later on in the initialization, it it reads the alternative_port and use_alternative_port settings and realizes that it's supposed to be listening on 5901 instead of 5900. So it closes 5900 and reopens 5901.

However, it doesn't tell glib that it's supposed to be listening on the new sockets instead of the old ones. This wouldn't be a problem if note for the port conflict with the X server module, because if vino-server had closed two sockets from port 5900 and immediately reopened two sockets on port 5901, they would have ended with the same file descriptor numbers, so glib would coincidentally still be listening to them. But since there was only _one_ socket open, the IPv6 socket, on port 5900, only one of the port 5901 sockets gets listened to.

The fix is to make sure to reset the sockets that glib is listening to whenever the port number changes. The attached patch does this.

There are other vino bugs in bugzilla which have been closed due to inactivity which are probably due to this root cause and fixed by this patch. I'm posting a new bug rather than reopening one of those because I'm not 100% certain they're the same issue.

Comment 1 David Mansfield 2012-10-02 15:48:08 UTC
i was just going to attempt to fix this myself after being frustrated for sooo long that it had never been fixed, only to find the bug, and the patch! Good for you Jonathan.  And good for me.

I can confirm the patch fixes the problem for me (caused in my case by having virtual machines running, which use 5900 ,5901 etc. for their vnc and/or spice consoles).

Note to maintainer: Please apply this!

Comment 2 David Mansfield 2013-02-20 02:41:29 UTC
Created attachment 699791 [details]
jonathan's patch updated to vino-3.6.2

i re-diffed this after correcting a small reject when applying to the latest source.

can this be applied please?  when libvirtd is used it takes port 5900 as soon as the vm starts and then vino becomes useless unless this obviously correct bugfix is applied.

Comment 3 Jason Haar 2013-03-12 23:31:53 UTC
Wow - this precisely describes the problem I'm having too

I use qemu-kvm - which uses spice or vnc on 127.0.0.1:5900

This causes exactly the same problem - "lsof -ni |grep :rfb" shows qemu-kvm on 127.0.0.1:5900 but shows vino-server on ipv6 port 5900 only!

Comment 4 Jonathan Kamens 2013-03-12 23:39:10 UTC
It's now the six-month anniversary of when I submitted this bug, with a patch.

The bug was actually reported much earlier than that (see the end of Comment 1 above).

Not so much as a peep from the alleged maintainer of this project.

What is going on?

Comment 5 David Mansfield 2013-03-13 15:01:58 UTC
Ha! I was just about to file the bug in the Gnome (upstream) bugzilla where (presumably) there would be a more legitimate maintainer, but I see Jonathan has been busy!

Just for documentation purposes, the upstream bug (opened 14 months ago):

https://bugzilla.gnome.org/show_bug.cgi?id=668187

Comment 6 Jonathan Kamens 2013-03-13 15:45:59 UTC
I already put a link to that bug in "External Trackers" above.

I exchanged email with the upstream maintainer today and he said he's going to try to get my patch into the next upstream release.

Thanks for updating it. :-)

Comment 7 Fedora End Of Life 2013-07-04 03:18:49 UTC
This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 8 David Mansfield 2013-07-08 14:14:46 UTC
I'm going to verify this. Upstream bug is now "resolved" as of 3/13 so in all likelihood this one is fixed.

Comment 9 David Mansfield 2013-07-09 20:30:35 UTC
This is confirmed fixed in f19. However, I don't have permission to change the status.  Can someone other than 'fedora end of life' come along and mark it fixed before 'fedora end of life' ruins one of the longest "patch-available"-to-"fix-in-distribution" cycles in recent history.


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