Re: Remote assistance for X

2010-01-03 Thread Karl J. Runge
On Sun, 3 Jan 2010, Warren Block wrote: > > > > I believe a workaround for you will be: > > > >ssvncviewer -listen -rfbversion 3.7 > > > > this reverts to the previous protocol version where there is no issue. > > Confirmed, that works fine with TightVNC servers from both of the > Windows sys

Re: Remote assistance for X

2010-01-03 Thread Warren Block
On Sat, 2 Jan 2010, Karl J. Runge wrote: On Sat, 2 Jan 2010, Warren Block wrote: Proto: RFB 003.008 Connected to RFB server, using protocol version 3.8 Enabling TightVNC protocol extensions Security-Type: 16 (rfbSecTypeTight) No authentication needed Desktop name "" ... ...and that's it. T

Re: Remote assistance for X

2010-01-02 Thread Karl J. Runge
On Sat, 2 Jan 2010, Warren Block wrote: > > Proto: RFB 003.008 > > Connected to RFB server, using protocol version 3.8 > Enabling TightVNC protocol extensions > Security-Type: 16 (rfbSecTypeTight) > No authentication needed > > Desktop name "" > ... > ...and that's it. The TightVNC server show

Re: Remote assistance for X

2010-01-02 Thread Karl J. Runge
On Fri, 1 Jan 2010, Warren Block wrote: > [SSL mode for x11vnc] > > I've tried it now and it does just what is needed for my setup! Very good. > Finally, a little feedback: > > On a Windows Vista system, AVG screamed that the netcat.exe from > ssvnc_windows_only-1.0.25.zip was a virus (don't

Re: Remote assistance for X

2010-01-01 Thread Warren Block
On Fri, 1 Jan 2010, Karl J. Runge wrote: On Fri, 1 Jan 2010, Warren Block wrote: Here are some examples that should work, I provide "prompt>" to indicate which machine the command is run on (and I skip your -c preference): supportee_host> ssh -t -N -f -L 5500:localhost:5500 $supporter_host

Re: Remote assistance for X

2010-01-01 Thread Karl J. Runge
On Fri, 1 Jan 2010, Warren Block wrote: > > ssh -t -c blowfish -N -f -L 5500:$supporterhost:5500 $supporterhost && \ > x11vnc -display :0 -localhost -connect localhost -ncache 10 I think that will work, but I believe (for extra safety/clarity if nothing else) you really want: -L 5500:localho

Re: Remote assistance for X

2010-01-01 Thread Warren Block
On Fri, 1 Jan 2010, Karl J. Runge wrote: remotehost="lightning" cmd="x11vnc -display :0 -localhost -connect localhost -ncache" ssh -t -c blowfish -R 5500:$remotehost:5500 localhost "$cmd" I think you mean: ssh -t -c blowfish -R 5500:localhost:5500 $remotehost "$cmd" right? You want to ssh

Remote assistance for X

2010-01-01 Thread Karl J. Runge
> remotehost="lightning" > cmd="x11vnc -display :0 -localhost -connect localhost -ncache" > ssh -t -c blowfish -R 5500:$remotehost:5500 localhost "$cmd" I think you mean: ssh -t -c blowfish -R 5500:localhost:5500 $remotehost "$cmd" right? You want to ssh to $remotehost and have the 5500 traff

Re: Remote assistance for X

2010-01-01 Thread Warren Block
On Fri, 1 Jan 2010, Brahim LARCHET wrote: Le 01/01/2010 18:45, Matthew Seaman a ?crit : x2x sounds like it fits the bill: http://www.freebsd.org/cgi/man.cgi?query=x2x&manpath=FreeBSD+Ports+7.0-RELEASE Synergy can do this too http://synergy2.sourceforge.net http://synergy2.sourceforge.net/fa

Re: Remote assistance for X

2010-01-01 Thread Brahim LARCHET
Le 01/01/2010 18:45, Matthew Seaman a écrit : > Warren Block wrote: >> A remote computer used by relatives is running FreeBSD and X. I'd >> like to find a method to work with the remote desktop to help them >> solve problems and maintain the system. >> >> The remote user's existing desktop should

Re: Remote assistance for X

2010-01-01 Thread Matthew Seaman
Warren Block wrote: A remote computer used by relatives is running FreeBSD and X. I'd like to find a method to work with the remote desktop to help them solve problems and maintain the system. The remote user's existing desktop should be shared, rather than creating a new session. Traffic

Remote assistance for X

2010-01-01 Thread Warren Block
A remote computer used by relatives is running FreeBSD and X. I'd like to find a method to work with the remote desktop to help them solve problems and maintain the system. The remote user's existing desktop should be shared, rather than creating a new session. Traffic and passwords should