X connection troubleshooting

[Mihails Nikitins]

Hi,

Please give me any hints to troubleshoot the situation.

Problem:
HP-UX 11.0 box cannot send output to any remote X server, the same task worked perfectly before.

Test:
export DISPLAY=1.2.3.4:0.0; sam

Other info:
- dtlogin and X is running locally on HP-UX box without problems;
- network connectivity is OK between X client and X server;
- similar HP-UX box executes the test perfectly (from the same network it can use the required X server);
- X server allows the both mentioned clients;
- of course, it seems to me that configuration/network environment changes were made :-) ;
- sam output:
# sam

The DISPLAY environment variable is set to "1.2.3.4:0.0", but
the current configuration won't allow sam to run on that display.

The DISPLAY environment variable may be incorrect, or, if you are running sam remotely, you may need to allow the remote system to access your local X server by typing
/usr/bin/X11/xhost +scpnm1
on your local machine.
Do you want to proceed using the terminal version of sam?
(yes or no) [yes]

Many thanks in advance for any ideas!

BR,
Mihail

[S.K. Chan]

Does it work when you run ..

# sam -display :0.0

or

# sam -display :0.0

[Mihails Nikitins]

Hi,

It works only if X-client and X-server is the same host (i.e. when I run sam locally).

BR,
Mihails

[Darrell Allen · Accepted solution]

Hi Mihail,

So it works from another HPUX box on the same subnet? Could a firewall change have been made and the failing system been over-looked?

Any changes made to the HPUX box?

When in doubt, blame the network admins! Just kidding, but if no changes were made on the HPUX box I'd followup with my firewall folk.

Darrell

[S.K. Chan]

Any changes made to the profile (.profile and .kshrc for example) ? If I'm not mistaken SAM (when executed) can reset the DISPLAY variable. It's better to NOT define the DISPLAY variable in the profile.

[Steve Steel]

Hi


It will be sam as indicated

It seems likely to me that the sam resets the DISPLAY

When SAM executes the .profile, it can actually also source the other login files if ENV is set in .profile.
In turn, the .kshrc or similar file reset the DISPLAY variable to an incorrect IP
address and hostname,possibly calculated from last and wtmp.
Thus SAM doesnt run in graphics mode because it could not use the display setting on the remote system( after the .profile )with the xhosts command.

Steve Steel

[Krishna Prasad]

Has anything changed around your xhost access?

It looks like you may need to run xhost + or xhost + hostname to allow x connections.

[K.Vijayaragavan.]

If you give "xhost +" in you local workstation before loggin into other workstation and exporting it's display to your workstation, then the sam error won't come.

I have an another theoratical approach read from man pages not really tried yet.

Is there anything to do with the .Xauthority files and using the command "xauth" to give authorization.

See the man page of "xauth" too.

This command is used to merge the xauthority file of one system to another system.

usage:

"xauth extract -$DISPLAY | rsh otherhost xauth merge"

-Vija

[Gnananandhan]

Check uniqueness in IP address(ensure no other m/c is given the same IP), If your system is enabled in DNS entry - check for reverse lookup also.

Regards,
Gnana A.

[Matt Hearn]

My suggestion would be to say to heck with it and run ssh. :) ssh is handy because it tunnels X through the encryption, and it automatically sets all your handy display values for you.

One thing to remember (that drove us nuts until we figured it out); if you log into the box, use "su -" to get to another username (probably root) and then ssh to another box, the displays get wacky. You're better off either just leaving the "-" off of the su or using sudo to ssh to the next box in your login trail, that keeps all the display variables kosher.

[Alex Glennie]

I'd keep in simple and use Xclock as a test case .... can you export the display and run that OK ?

If not exit out of CDE login as root and test, then as a user do the same but this time su to root ? Is there a difference ? ie is the su someway involved ?

If yes it's likely this is Zauthentication wrt .Xauthority files : easy way to check is diable it using /usr/dt/config/Xconfig :see Dtlogin*authorise flag . For the change to take effect CDE/X will need to be restarted.

If no I'd suspect this is network connectivity / simple xhost problems : create an /etc/X0.hosts file and add any remote hostname you wish to allow access to the local display then restart X, it will save you having to run xhost but will need networking/hostname resolution to be working correctly to work

[Mihails Nikitins]

Many thanks for all your comments! The reason was wrong
default gateway in netconf. I changed default route online, then system reboot activated wrong default gateway.

The problem was so sophisticated to solve because
IP packets went two different ways when replying requests and when initiating connections.
It was possible to establish telnet connections from remote networks, but it was not possible call X-server in the remote network. That's why I could not notice that something is wrong with networking.

As regards to failed display exports in the same network, it was another error in my experiment.

Thank you again!

BR,
Mihail