Fellow Sun Managers,
Well, this turned out to be a "classic" quick sun-managers turnaround,
many thanks to the Sun-Managers community at large. Many thanks to any
future responses I may receive, thank you all.
Many thanks to Craig Russell <crussell_1969@yahoo.com>, whose response
clued me in to what was going on. Little did I know, it had to do with
my network layout. The soultion for me was to run /usr/sbin/in.routed.
Originally there was just a default route to my default Internet router
on server B, which resulted in a more complex data path and thus was the
root of my problem.
-------------------------------------------------------------------------------------------------------
Explaination:
The reason I had this problem is that I have 2 routers on the subnet
that server B is on, one is a default router to the Internet, the other
is a route to the corporate network. Naturally, without in.routed
running, the default route pointed to the Internet router (a very busy
router), which would then forward the packet to the corporate router
(heading towards server A), which would also have to forward the packet
to another ethernet port that I was working from.
Physical Layout:
Inetrouter (ethernet interface)
|
Server B
|
Corprouter (2 ethernet interfaces)
|
Server A
pre in.rotued data path: Server B -> Inetrouter (bounce-thru) ->
Corprouter -> Server A
(keep in mind that with the above path, the packet has to bounce off of
the Inetrouter thru the ethernet interface twice, once in, once out,
then on to the Corprouter and on to Server A)
post in.rotued data path: Server B -> Corprouter -> Server A
This entire roundabout path eventually put enough latency into the event
that the connection would break and result in the error message I had
received. Since I really don't see that problem with other protocols run
between the two servers, I guess it is just that X is fickle as to the
timeliness and sequence of the packets it is receiving (in other words,
it gives up easy if excessive time or out of sequence occurs on a packet
stream).
If you see this message in a summaries archive, and have any Q's about
it (I hope i'm being clear enough), e-mail me and i'll try to clarify
the situation better.
------------------------------------------------------------------------------------------------------
The only response I got:
This error usually means that the X connection is timing out due to a
network bottleneck. Are the two servers on different subnets with a
router in between? If they are on the same network then it might be an
issue with saturated bandwidth, especially if the 10mb LAN is shared
instead of switched.
This won't fix your X problems, but you can create your metadevices
from the command line instead of the GUI tool (my preferred method, so
I can do it over a 28.8 modem connection!). Do a man on metainit and
if you need help with this part shoot me an email.
Craig Russell
RBC-DS
-----------------------------
My original post:
Fellow Sun Managers,
I am having a problem with running remote X apps from one server to
another, which is hindering my ability to run the disk config utility
"metatool", which I need to run in order to get a mirror going on some
HD's in a D1000 that really need to be mirrored (and also add a warm
spare for redundancy).
Here is basically what happens:
I "xhost +" on server A, telnet from Server A to Server B, set the
correct DISPLAY variable, then run any X app (such as metatool or
xeyes). The app starts and runs successfully, but between 5 and 60
seconds, the app quits and the following error shows up in my telnet
session to server B:
XIO: fatal IO error 131 (Connection reset by peer) on X server
"192.251.235.20"
after 2232 requests (2227 known processed) with 0 events
remaining.
My setup:
Server A:
Sparc 20 with 64 megs of RAM, running Soalris 7 server, 5/99.
Server B:
Ultra Enterprise 250 with 256 Meg of RAM, running Solaris 7 server,
5/99.
The network between the two servers is a 10MBPS LAN.
I cant run a local X console on the 250, it has no graphics card and I
don't have a spare card :(.
Many thanks for your response and assistance, I will summarize findings
and post when solved or in a few weeks, whichever comes first. Please
respond to me and not the list, as per the Sun Managers guideline.
Thanks,
Gil
-- gjy@crc.com | (@X@) ----------------|--------------------oOOo--(_)--oOOo---------- Corporate Network Manager Coleman Research Corporation - "To win one hundred victories in one hundred battles is not the acme of skill. To subdue the enemy without fighting is the acme of skill." Sun Tzu, The Art of War
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:25 CDT