On Thu, May 7, 2015 at 2:01 PM, Gene Heskett <ghesk...@wdtv.com> wrote:
> On Thursday 07 May 2015 12:16:44 Jon Elson wrote: > > On 05/07/2015 02:20 AM, Gene Heskett wrote: > > > I have been able to export the x session to this box forever, and it > > > has worked nominally well, till now. > > > > > > But this machine now has debian 7.8 (wheezy) on it, and the lathe > > > just got its drive reformatted and has the binary-hybrid.iso > > > installed on it. > > > > Much easier than trying LinuxCNC, use xclock. It will work, > > or not, hopefully give an error message, and only takes a > > second or so. If xclock brings up your analog clock dial, > > then most of the X support is going to work. The one other > > thing that is required is some kind of 3D rendering support, > > if you are going to use Axis. > > > > If xclock does NOT work, then your X server is rejecting the > > connection request from the LinuxCNC system. This is > > STANDARD behavior! > > > > Here's a quote from my bag of tricks file: > > to allow remote systems to use your X screen > > 1. get your cookie with : > > xauth > > list > And get this: > xauth> list > coyote.coyote.den:0 MIT-MAGIC-COOKIE-1 e7b9e1a766fdb4aa1d23f7ad305baf17 > [fe80::21f:c6ff:fe62:fcbb]:0 MIT-MAGIC-COOKIE-1 > e7b9e1a766fdb4aa1d23f7ad305baf17 > coyote/unix:0 MIT-MAGIC-COOKIE-1 e7b9e1a766fdb4aa1d23f7ad305baf17 > > > 2. copy the line with mouse > which line, or the whole thing? > > > 3. on remote connection, do > > xauth > "list" on lathe is totally differently formatted > xauth> list > lathe/unix:0 MIT-MAGIC-COOKIE-1 384f881f7983355c1b2b3fe7dc8e8925 > lathe/unix:11 MIT-MAGIC-COOKIE-1 2da267aca6bea446de8cc445ed10474c > lathe/unix:10 MIT-MAGIC-COOKIE-1 aa5cf4dbb7194605bdfc87a386f3c9f6 > lathe/unix:12 MIT-MAGIC-COOKIE-1 9a6c36c2e37d080cf74e7bb9f47142de > > Which looks more sensible than the first paste from coyote above. > > Directions plz? > > > add <paste mouse line here> > > exit > > and it should now allow the remote > > system to connect to the X screen > > > > It seems like there was some other option that needed to be > > hacked in the X config file on some systems. > > See > > http://www.cyberciti.biz/faq/x11-connection-rejected-because-of-wrong- > >authentication/ for some more things to check. The last item there is > > the > > one I was thinking of. > > > Thanks, Jon > > Humm, the last test item is running xeyes, and while it does report the > FOREGROUND and BACKGROUND colors are undefined, it works and they are > following the mouse as it moves. What does that tell us? > > Cheers, Gene Heskett > On your first xauth on coyote, it looks like an IPv6 magic cookie. Do you have IPv6 enabled? This here: [fe80::21f:c6ff:fe62:fcbb]:0 looks suspiciously like some kind of local IPv6 address. Try disabling IPv6 on coyote. Ssh will automagically try to make it's connection on IPv6 and if it's not available, can either sit there till it times out, or cause other problems. You might try connecting with this string: #ssh -4 -Y <machine? -vvv the -4 tells ssh to skip the IPv6 attempt and go right to an IPv4 connection. Mark ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
