Hi guys,

got another query abt Solaris.

Recently, i've been using X-manager to access my solaris systems and i came upon this strange occurance.

If i were to start using it for some scripts testing, i realise if i keep the system running in some form of loop-processing, my X-win session will automatically be terminated. i do a simple test by writing a endless while loop and let it run in my x-win, with the time captured to a txt file. true enough, at 30mins sharp, my session is terminated. i've test on few machines with all same results.

Just curious, is this a feature of Solaris ? and what is causing the disconnection of my X session ?

J.J

This is definitely *not* a Solaris feature, perhaps a bug between Xmanager and the screensaver. Try to disable or change the screensaver delay and see if the 30mn is related to that.

Hi jlliagre,

i tot so too...for once, i tot i discover a new feature in solaris...

i'm now running snoop to see what is the traffic like when my Xwin d/c.
interesting thing to note is nothing is captured in my /var/adm/message relevant.

You should try to look too, on the PC side, the Xmanager log files.

just curious...

i discover my telnet now also have the same results ?

is there any setting that can be set in solaris to limit the connection time ?

Is there a firewall between your PC and the Solaris server, or on one of them ?
Did you capture network traffic (snoop) and process calls (truss) when the communication ends ?

Hi Jlliagre/All,

more interesting findings.

jlliagre : yup..there is a firewall in my company...all routes goes through it...
the snoop doesn't show any terminating messages at all...(or i might have miss it...)

however, i discover one of my parameter , tcp_keepalive_interval has been set to 1800000 (which is 30mins i think)
i found out the default for this value should be 7200000 (2 hours)
i tried changing this value back to 7200000, and wala~ my telnet n X-win sessions got extended to 2hrs~
whereelse on my another machine, which is 2 machines directly connected up with telnet and X-win (doesn't goes through my company network), doesn't seems to be affected by this paremeter at all. the telnet session between them doesn't seems to terminate at all, even after 2 days!

further read up found out that this tcp_keepalive_interval parameter is only used if there is a probe to it. Now what i don't understand is, "what" is providing this probe ? isit the firewall or the connecting system ? i'm pushing all the blames to firewall as i cant explain to myself why the 2 directly connected machines doesnt disconnected with tcp_keepalive_interval set to 7200000, which the machine connected through my company network does.

now reading on all the differnt types of parameter which i could played with.

The tcp_keepalive_feature is indeed the key of the problem.
Its purpose is to have the system dropping connection when the peer side is unresponsive. The name is somewhat misleading as instead of keeping alive a connection, which is what just happen forever when nothing is done, its real purpose is to test connections and kill these where the other side is unresponsive. It's more a session "killer" than "keep aliver".

The problem here is that the probes are not answered, and your tests shows a firewall is the culprit, which I was suspected.
As the probe packets do not carry data, the firewall is probably dropping them thus the connection close.
Raising the keepalive interval to a sufficient value shouldn't be a problem, e.g. to 8 hours or more depending on the maximum idle time you need, just check the tcp connection table doesn't grow too much (netstat -a).

Hi jlliagre,

"who" is producing the "probe" packets ?

eg: say i got machine A, B and a SUN server.
I change the tcp_keepalive_interval at the SUN server to say 4 hours.
A uses X-win to connect to SUN Server via a network with firewall.
B uses telnet to connect to SUN server via a network with firewall.

correct me if i'm wrong from here onwards,
the SUN server keep tracks of the keepalive interval for A and B...
so the SUN server is the one tat "probe" A and B ?
but for every probe to A and B, the "reply" back doesn't contain any data, so the firewall will drop these "reply".
within the next 4 hours, after the keepalive value in SUN server counts to zero, the connection is cut off.

What you describe is indeed my understanding.

Just not only the probe reply doesn't contain any (payload) data but the probe itself too, so the firewall may drop the probe before a reply has a chance to be sent.

Roger jlliagre~
thanks~