KVR :: Muse Research and Development » Remote Control fails after OS upgrade [View Original Topic]
There are 6 posts in this topic.

ndurant - Sat Jul 02, 2011 2:05 pm
I recently bought a second Receptor (2 Pro Max), and noticed it was running an older version of the OS (1.8.20100623) so decided to upgrade to the latest (1.8.20100924).

The upgrade went smoothly, but I can no longer connect to the Receptor using Remote Control. The Receptor appears in the list ok, but when I try to connect, the status "Connection initiated" comes up, but it fails to get any further, then brings up an error box saying "Failed to connect to server" message. Rebooting doesn't help. I've also tried connecting using the latest TightVNC, with the same results. Meanwhile connection to my first Receptor still works fine.

Any ideas? It looks like the VNC server is no longer running on the upgraded Receptor or something...is it fixable?

Hope someone can help - I need this!!

Neil
ndurant - Sat Jul 02, 2011 3:26 pm
Just to add to my previous post, I checked the System Log.txt on the Receptor drive, and I'm pasting what I believe to be the relevant parts below:



Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking: 02/07/2011 00:20:10 ***************************************
Jul  2 00:20:10 Receptor-2 receptor-networking: 02/07/2011 00:20:10 *** XOpenDisplay failed (:0)
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking: *** x11vnc was unable to open the X DISPLAY: ":0", it cannot continue.
Jul  2 00:20:10 Receptor-2 receptor-networking: *** There may be "Xlib:" error messages above with details about the failure.
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking: Some tips and guidelines:
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:  * An X server (the one you wish to view) must be running before x11vnc is
Jul  2 00:20:10 Receptor-2 receptor-networking:    started: x11vnc does not start the X server.  (however, see the
Jul  2 00:20:10 Receptor-2 receptor-networking:    recent -create option if that is what you really want).
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:  * You must use -display <disp>, -OR- set and export your $DISPLAY
Jul  2 00:20:10 Receptor-2 receptor-networking:    environment variable to refer to the display of the desired X server.
Jul  2 00:20:10 Receptor-2 receptor-networking:  - Usually the display is simply ":0" (in fact x11vnc uses this if you forget
Jul  2 00:20:10 Receptor-2 receptor-networking:    to specify it), but in some multi-user situations it could be ":1", ":2",
Jul  2 00:20:10 Receptor-2 receptor-networking:    or even ":137".  Ask your administrator or a guru if you are having
Jul  2 00:20:10 Receptor-2 receptor-networking:    difficulty determining what your X DISPLAY is.
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:  * Next, you need to have sufficient permissions (Xauthority)
Jul  2 00:20:10 Receptor-2 receptor-networking:    to connect to the X DISPLAY.   Here are some Tips:
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:  - Often, you just need to run x11vnc as the user logged into the X session.
Jul  2 00:20:10 Receptor-2 receptor-networking:    So make sure to be that user when you type x11vnc.
Jul  2 00:20:10 Receptor-2 receptor-networking:  - Being root is usually not enough because the incorrect MIT-MAGIC-COOKIE
Jul  2 00:20:10 Receptor-2 receptor-networking:    file will be accessed.  The cookie file contains the secret key that
Jul  2 00:20:10 Receptor-2 receptor-networking:    allows x11vnc to connect to the desired X DISPLAY.
Jul  2 00:20:10 Receptor-2 receptor-networking:  - You can explicity indicate which MIT-MAGIC-COOKIE file should be used
Jul  2 00:20:10 Receptor-2 receptor-networking:    by the -auth option, e.g.:
Jul  2 00:20:10 Receptor-2 receptor-networking:        x11vnc -auth /home/someuser/.Xauthority -display :0
Jul  2 00:20:10 Receptor-2 receptor-networking:        x11vnc -auth /tmp/.gdmzndVlR -display :0
Jul  2 00:20:10 Receptor-2 receptor-networking:    you must have read permission for the auth file.
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:  - If NO ONE is logged into an X session yet, but there is a greeter login
Jul  2 00:20:10 Receptor-2 receptor-networking:    program like "gdm", "kdm", "xdm", or "dtlogin" running, you will need
Jul  2 00:20:10 Receptor-2 receptor-networking:    to find and use the raw display manager MIT-MAGIC-COOKIE file.
Jul  2 00:20:10 Receptor-2 receptor-networking:    Some examples for various display managers:
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:      gdm:     -auth /var/gdm/:0.Xauth
Jul  2 00:20:10 Receptor-2 receptor-networking:      kdm:     -auth /var/lib/kdm/A:0-crWk72
Jul  2 00:20:10 Receptor-2 receptor-networking:      xdm:     -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk
Jul  2 00:20:10 Receptor-2 receptor-networking:      dtlogin: -auth /var/dt/A:0-UgaaXa
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking:    Only root will have read permission for the file, and so x11vnc must be run
Jul  2 00:20:10 Receptor-2 receptor-networking:    as root.  The random characters in the filenames will of course change,
Jul  2 00:20:10 Receptor-2 receptor-networking:    and the directory the cookie file resides in may also be system dependent.
Jul  2 00:20:10 Receptor-2 receptor-networking:    Sometimes the command "ps wwwaux | grep auth" can reveal the file location.
Jul  2 00:20:10 Receptor-2 receptor-networking:
Jul  2 00:20:10 Receptor-2 receptor-networking: See also: http://www.karlrunge.com/x11vnc/#faq
Jul  2 00:20:10 Receptor-2 rdm: X start-up failed - trying VESA fallback


Any ideas?

Neil
gary@museresearch - Wed Jul 06, 2011 8:50 am
Hey Neil,

Some times this can be fixed simply by changing the Receptor TCP/IP setup from crossover to auto dhcp and then back to crossover (or visa versa depending on how is it set now) If that does not work we will have to do some troubleshooting. I can best help you by going to the plugorama help desk and opening a ticket. http://www.plugorama.com/helpdesk.php

Thanks,
Gary
Muse QA and Support
ndurant - Wed Jul 06, 2011 1:03 pm
Thanks Gary, that seems to fix the issue, although not permanently, but at least it's a workaround to get me going if/when it does happen!! Many thanks Smile
rosenbutter - Wed Sep 07, 2011 5:13 pm
Hy Gary.
I've the same problem with my Receptor too.

Is there an Update or some possability to change the fact
that I always have to change to Crossover Mode and back to DHCP ?


Thanks,
J
rosenbutter - Wed Sep 14, 2011 4:47 pm
I found a solution that works for me.

I just set up the Network Settings to manual and after the reboot it works anyway without refusing the connection.

Greetings.

There are 6 posts in this topic.