Strange telnet problem 2

[KenCunningham]

Hi all. I may have posted this previously, but having thought I had resolved the problem using snoop from another server, it seems to have reappeared.

Basically, between about 17:00 and 8:30 the following morning (and all day at weekends), any telnet sessions to my M4000 server are dropped after a couple of minutes connected. I can see nothing in any configuration files which might affect this, and there is nothing in /var/adm/messages to indicate a problem of any kind.

Just on the off-chance, any ideas? Thanks.

The internet - allowing those who don't know what they're talking about to have their say.

 

[bluedragon2]

Just throwing out some ideas...

Any login script being used?
Happening only in a particular shell?
Anything in a profile that could be causing it?
Going through any device that may have time of day usage rules?

[Blue]Blue[/Blue] [Dragon]

If I wasn't Blue, I would just be a Dragon...

 

[KenCunningham]

Thanks Blue, none of the above I'm afraid. Still investigating here.

The internet - allowing those who don't know what they're talking about to have their say.

 

[cndcadams]

Ken;

How about this;

couple different types of timeout values

A) The login session.


The entry in the /etc/default/login file:
# TIMEOUT sets the number of seconds (between 0 and 900) to wait before
# abandoning a login session.
#
#TIMEOUT=300

defines the number of seconds the login process will wait on an attempted login for a response to the login prompt. For example, if you have the TIMEOUT value set to 120, then when you "telnet ", you will have 120 seconds, or 2 minutes, to enter a login name before it closes the connection.

The default is 300 seconds, or 5 minutes.

B) The shell session. (Korn and Bash shells only, /usr/bin/ksh and /usr/bin/bash)

The TMOUT environment variable is what controls Korn and Bash shell inactivity timeout. If it is unset, or has a value of 0, then timeout is disabled. If it is set to a value greater than zero, then the shell will terminate if a command is not entered in the specified number of seconds in the TMOUT variable.

The TMOUT variable can be set in /etc/profile for all users, or in an individual's $HOME/.profile.

Note: There is no TMOUT equivalent for either the bourne (/bin/sh) or C (/bin/csh) shells. Also, it only works for login sessions which use simple shells (like telnet or rlogin). It will NOT automatically logout from a CDE or Openwindows session. However, if the TMOUT variable is set in /etc/profile as shown above, any terminal window within CDE will exit after exceeding the TMOUT idle value. That might not be a desirable thing.


Product
Solaris 10 Operating System
Solaris 9 Operating System
Solaris 8 Operating System

 

[cndcadams]

couple other things

Does it happen when you ssh?

Also see below

XSCF Shell terminal

* You can use the XSCF Shell with SSH or telnet connection.
* Either of the two XSCF-LAN ports can be used concurrently by more than one user. (Note 1)
* Switching to the domain console is enabled by the console(8) command. For details on changing these default keys, see the description on the console(8) command.
* After login, if the XSCF Shell is not used for a certain period, the user is forcibly logged out. For details on setting XSCF session timeout, see the description on the setautologout(8) command.

 

[bluedragon2]

One other thing I thought of (which I do not use but remember it from a class) RBAC I think has usage times.

[Blue]Blue[/Blue] [Dragon]

If I wasn't Blue, I would just be a Dragon...

 

[KenCunningham]

Thanks all, and apologies for my tardiness in responding, but I was off on Friday. Neither TIMEOUT, TMOUT or RBAC are set/used on this server.

What is particularly odd in this circumstance is that the problem only manifests itself in the evenings and all day at weekends. There must therefore be something happening to cause the issue, but I'm darned if I can find anything! If anyone has other ideas, please throw them in.

Thanks again.

The internet - allowing those who don't know what they're talking about to have their say.

 

[cndcadams]

Ken;

Does ssh have the same issue?

Chris

 

[KenCunningham]

I'll check that out Chris, thanks.

I read elsewhere that possibly keeping the NIC alive via ntp might help too, so I have set this up and should find out sometime over the next few hours. Will report back!!

The internet - allowing those who don't know what they're talking about to have their say.

 

[cndcadams]

have you had a chance to test ssh?

When the telnet times out are you actually doing work or is it idle for a couple minutes?

Have you timed it out to see how long before it times out?

any progress with the ntp

 

[KenCunningham]

Hi Chris, apologies for not getting back to you before now, we've had a bit of storm disruption. I haven't tested ssh as yet, though ntp does seem to have helped, unless I'm imagining things.

I ran a ping test from another server over Wednesday night and it showed that the ping wasn't returned for something like 5 hours in one minute intervals seemingly randomly throughout the night, but only when our Customer Service Centre is inactive between 16:45 and 8:45 the next day (though that may be a red herring too). So, the plot thickens! I intend doing some more digging next week and will keep you abreast of what I find. In the meantime, any other bright ideas welcomed.

The internet - allowing those who don't know what they're talking about to have their say.

 

[KenCunningham]

Resolved this morning - problem seems to have been the gateway. Setting up a contant ping to it seems to keep it alive and working, so whether or not it's a perfect solution, it seems to work. Thanks for your input folks!

The internet - allowing those who don't know what they're talking about to have their say.

 

[tarn]

Hmmm ... a bit late reading this but I would have suspected a session limit on the firewall (or a router) and the fact it happened in the evening is due to the allowed session expiring (length of time since initial connection at the beginning of that day).

On the subject of your workaround (gateway ping) you could set up IPMP so this would be a BAU (Business As Usual) process for the interfaces though you have to consider if your network services (managers) are happy to be receiving the extra udp traffic that your IPMP test interface @IP's would be sending?

I just love these things that seem to have no rime or reason to the cause

Laurie.

 

[KenCunningham]

Hi Laurie, thanks for your input, it's much appreciated. I might look into your suggestion when I return to work in January, so in the meantime, enjoy your holiday and all the best for 2012!

The internet - allowing those who don't know what they're talking about to have their say.