GNOME Bugzilla – Bug 319798
vino preferences shows :0 for all users
Last modified: 2009-06-25 01:55:56 UTC
Version details: vino-2.10.0-4.1 Distribution/Version: Fedora Core 4 Reproduce: 1. Let multiple users login on the same system (such as a terminal server). 2. Run vino-preferences Problem: You see that all users show the same port number zero: "Users can view your desktop using this command: vncviewer foo.bar.tld:0" Expected results: I expect to see :0, :1, :2, etc. Note1: As root, running lsof, I see that TCP ports 5900, 5901, and 5902 are listening. Note2: It may be a separate bug, but vncviewer connections fail. (I did verify my vino preferences to allow remote desktop. Also, I do not have any firewall installed.) $ vncviewer localhost:1 VNC Viewer Free Edition 4.1.1 for X - built Aug 4 2005 06:43:41 Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Tue Oct 25 16:43:35 2005 CConn: connected to host localhost port 5901 CConnection: Server supports RFB protocol version 3.7 CConnection: Using RFB protocol version 3.7 main: read: Connection reset by peer (104)
Confirming issue as well on Ubuntu. Downstream bug: https://launchpad.net/distros/ubuntu/+source/vino/+bug/6744
*** Bug 333049 has been marked as a duplicate of this bug. ***
If you follow the launchpad, it leads to a workaround script: https://help.ubuntu.com/community/CorporateUbuntu#head-3855c76877c91aaa4ba50d809f41f019d335e53e
I guess we can show the server port number instead of display one. What do you think? According to http://live.gnome.org/RoadMap#head-7fa1a2dfa1009d1933f26546f69701e7f78e1b52 dbus will replace libbonobo. What do you think about this? We could use dbus to get that information from server.
Created attachment 78655 [details] [review] Add initial dbus support, and fixes this bug With this patch i've added initial dbus routines in vino. The only method available is GetServerPort(), which is used in vino-preferences to get the port on the server running. As usual, you can comment, i'm waiting.
Jonh, this broadly looks pretty good. Comments follow. Please go ahead and commit the patch once you've fixed up this stuff. - Don't forget to retain the copyright notices from gs-listener-dbus.[ch] - I'd suggest VinoDBusListener instead of VinoListener and vino-dbus-listener.[ch] instead of vino-listener-dbus.[ch] - Note that "bus name" is the recommended terminology these days instead of "service" ... a "service" is something D-Bus knows how to start - We need a D-Bus object for each screen which Vino is exporting, so I'd suggest: #define VINO_DBUS_BUS_NAME "org.gnome.Vino" #define VINO_DBUS_INTERFACE "org.gnome.VinoScreen #define VINO_DBUS_OBJ_PATH "/org/gnome/vino/screens/%d" - Don't define API_SUBECT_TO_CHANGE and require dbus-1 >= 0.95 (that was the first version with a frozen API) - GetServerPort() should return e.g. 5900, but the command displayed in the dialog should show e.g. "vncviewer blaa:0" ... so subtract 5900 from the port returned if it's in the range 5900-6000 perhaps - In vino-preferences.c, you'd get the screen number by: GdkScreen *screen; int screen_num; screen = gtk_window_get_screen (GTK_WINDOW (window)); screen_num = gdk_screen_get_number (screen); - The g_type_init() in vino-preferences.c is not needed - Unref the connection in vino-preferences. using dbus_g_connection_unref() - The port should really be a read-only GObject property of VinoServer, and the accessor functions with the rest of the accessor functions in vino-server.[ch] - I don't think the vino_dbus_listener_acquire() API makes sense: 1) We should just do all that stuff when the server property is set during construction 2) We don't want to report an error from the API - we should just print an error (not a debug message) if there is a problem - I'm disappointed that VinoDBusListener is using the lowlevel dbus API rather than the glib binding. The main reason for that AFAICS is that we need to set disconnect_on_exit. Maybe there are other reasons too. I'd like to see this fixed, but it can be done after we add the code. - You don't need a finalize() method, so just remove it - Don't need unregister_handler(). Just remove it - I don't think we need to add a filter function, do we? The object message handler should be enough - I'm very dubious of the AddMatch and Disconnected handling code
Created attachment 78768 [details] [review] Patch corrected I've tried to follow Mark's advices. Except the comment about 'lowlevel dbus API' and other one about 'AddMatch and Disconnected handling code', all stuff was corrected.
I've received a comment in my blog (http://www.bani.com.br/index.php/2006/12/24/improvements-in-vino): "btw, it would be nice to have a dialog which tells you which ports you have to forward in your router.." What do you think about to show port number instead of display one?
Has this been applied, or fixed otherwise, or has this bug been forgotten?
From the ChangeLog file, this bug should already be fixed. [...] 2006-12-21 Jonh Wendell <jwendell@cvs.gnome.org> Added initial d-bus support, fixing bug #319798 * configure.in: Require dbus-glib-1 * server/vino-dbus-listener.[ch]: New files [...]