cannot display x11 applications on server back to my mac running x11

Ronnie - welcome to discussions!

Perhaps you have things mixed up?

You have to choose to either set DISPLAY and open ports 6000-6039 (and skip the ssh tunneling of X11 traffic) or you set up ssh tunneling on the server end and the client end and leave DISPLAY alone (ssh will set it properly when you log in)

Let's pick one and work through your problem....

Ronnie-

I have the same error using three different ways for connecting:

Method 1:
ssh -X -l username hostname "remote app"

Method 2:
xhost + in the local xterm
ssh hostname
export DISPLAY=macip:0.0
appname

Method 3:
ssh -X -l username hostname "xterm"
in the new xterm run appname

very simple basic X apps work fine, but complex apps fail. With method 2 the remote machine complains it cannot connect to remote display and with methods 1 and 3 it flashes a window on the screen, gives a short error report in the console and dies.

I forgot to mention that I was also able to work properly with x11 last weekend, but then during the week I upgraded my machine to 10.4.6. That is the only change made to the machine.

I don't think it has anything to do with your remote system: something has changed with X11 and 10.4.6. Try doing a local display of xterm (that is, from your mac to itself), but rather than using default DISPLAY 😮.0, set DISPLAY to your local IP address, or 127.0.0.1.... setenv DISPLAY 127.0.0.1. Or, do it all via command line: xterm -display 127.0.0.1:0.0. This now fails. It all worked fine under 10.4.5 (try "localhost:0.0", try your real IP address -- they all fail under 10.4.6!)

Dual 1GHz PPC G4 Mac OS X (10.4.6)

...and as I wrote that reply, it got me thinking: The problem is Apple changed the x11 defaults used by the server. Compare old and new values using "defaults" from the command line:

old, pre-10.4.6:
% defaults read com.apple.x11
{"done xinitcheck" = 1; }

new 10.4.6:
% defaults read com.apple.x11
{
"NSWindow Frame x11_prefs" = "16 656 478 338 0 0 1280 1002 ";
depth = -1;
"done xinitcheck" = 1;
"enable fakebuttons" = 1;
"enable keyequivalents" = 0;
"enable systembeep" = 1;
"no_auth" = 1;
"nolisten_tcp" = 1;
"sync_keymap" = 0;
}

So, one way to fix this is to delete and then reset these to same value as pre-10.4.6:

% defaults delete com.apple.x11
% defaults write com.apple.x11 done xinitcheck 1

That now allows you to use TCP to access your local server!


Dual 1GHz PPC G4 Mac OS X (10.4.6)

It worked!

Thank you very much for your hint on this issue!

MacBookPro Mac OS X (10.4.6)

Hi pbuck,
Ah, data; that helps! You don't have to delete all of those options. The one that disrupts connections made by setting the display on the remote machine is the nolisten_tcp option. If you set that to 0 or "no", your apps can connect directly to the window server on your machine via tcp.

However, that doesn't apply to a secure shell tunnel. I don't know what happens between-the-sheets but maybe secure shell negotiates with XWindows directly because the above setting doesn't affect the ability to do window forward through a secure shell tunnel. Of course for that you have to have "X11Forwarding yes" in the sshd_config file on the server and you're supposed to have the "ForwardX11 yes" set in the ssh_config file on the client, although I've gotten by without the latter. After that, all you have to deal with is X11 itself, or more specifically, the X11 Security Extension.

Newer versions of X11, such as the one that ships with Tiger, have an operative Security Extension. Thus, they have more stringent requirements of dangerous applications. I don't really know how to deal with it outside of SSH but again OpenSSH will handle the negotiation for you if you use the "-Y" option instead of the -X option.
--
Gary
~~~~
I never thought that I'd see the day where Netscape is free
software and X11 is proprietary. We live in interesting times.
-- Matt Kimball <mkimball@xmission.com>