Red Hat Bugzilla – Bug 856772
vino-server doesn't listen on ports properly when switching to alternative port
Last modified: 2014-06-18 05:15:57 EDT
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.
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!
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.
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!
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?
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
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. :-)
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.
I'm going to verify this. Upstream bug is now "resolved" as of 3/13 so in all likelihood this one is fixed.
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.