Telnet sessions closed randomly

[Julio Rodriguez_4]

HP-UX 11
telnet sessions are being closed Current
lanadmin -x 0 :
Speed = 100 Full-Duplex Auto-Negotiation-OFF
lanscan


Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
0/0/0/0 0x00306E03AA07 0 UP lan0 snap0 1 ETHER Yes 119

[Michael Tully]

Hi,

Is any information being logged into
'/var/adm/syslog/syslog.log' file
for the telnet sessions. Perhaps this
may indicate something. The information
you have provided will generally have
to do with point-to-point file
transfer slowness and lost or collided
packets. From your attachment there does
not seem to be a default route.

Cheers
~Michael~

[Steven Sim Kok Leong]

Hi,

Verify "randomly".

Check your login records for those telnet sessions that were closed. Is it a fix time period? Some timeouts you need to watch out for are:

1) shell idle timeout

# echo $TMOUT

To validate this, run a loop with the shell in a telnet session and check whether the telnet session still gets terminated:

# while sleep 10;do echo date;done

2) firewall session timeout

Check for any settings on the network-based firewall between client and server whether a session timeout (max. time a session can last) has been specified.

Apart from the timeouts, check for network connectivity health, monitor the ping health status during your entire telnet session (from start to termination) through a continuous ping:

# ping $server_ip

Hope this helps. Regards.

Steven Sim Kok Leong

[Steven Sim Kok Leong]

Hi,

Oops, a typo.

# while sleep 10;do echo date;done

should be:

# while sleep 10;do date;done

In order not to eat up too much resources, you can also do (at 15 mins interval):

# while sleep 900;do date;done

If all these do not help, the method you should use is:

1) run tcpdump (or other sniffer program) on your client's NIC interface

2) run tcpdump (or other sniffer program) on your server's NIC interface

3) if necessary, run it on both your firewall's inbound and outbound NIC interfaces

4) Analyse the TCP packets (order of seq. no.s, ACK no.s, TCP flags) for abnormalies.

Hope this helps. Regards.

Steven Sim Kok Leong

[Julio Rodriguez_4]

The problem continues without any time pattern, even that is almost without load
This machine is running Progress with a 30 users, averaging 60% Idle , and Load average <3
I've made this:
ndd -set /dev/ip ip_ire_gw_probe
ndd -set /dev/tcp tcp_ip_abort_interval 120000
ndd -set /dev/tcp tcpip_ip_abort_cnterval 25000

Also have reseted the routing tables
But it continues failing

[Steven Sim Kok Leong]

Hi,

Can you try the continuous ping method? Verify (or eliminate) the interconnecting network as a fault first.

If ping works, then IP (layer 3) can be eliminated as a cause and the fault can be narrowed to TCP (layer 4) all the way to application (layer 7).

Try a step-by-step troubleshooting approach. Hope this helps. Regards.

Steven Sim Kok Leong

[sven verhaegen]

hi ,

do you get any messages like

"connection reset by peer"

or likewise on telnet in the syslog , any other message from telnetd around the hang time could be good info also , can you simulate the problem , that means can you see the problem happening swiftly and react to it or do you need to wait for a user to call you , as said by others in this forum , lots of timers play on the IP and TCP level , one of them just might tick off due to some delays.

If tuning of ther parameters is no solution and if the ping has no similar issues (packet loss for prolongued times) then we might even consider tracing the issue , are you knowledgable in network packets and traces ? if so there is a very effective way of finding out just what is going on , it does require you to be able to reproduce the problem 'at will' or see it happening and intervene fast , for instance , the telnet takes only 1 to 5 minutes to get trown out after starting, I suppose the telnet just stops while someone is working so what you could do is use NETTL on the HP-UX and trace what exactly is going on

procedure

nettl -start
nettl -tn pduin pduout -tm 10000 -e all -f /dir/filename


reproduce the problem

what this does is in fact create atracefile called filename.TRC0 in the directory you specify .. it gas a size of maximum5Mb , if filled upo it will copy tot afile called filename.TRC1 then overwrite data in .TRC0 and folow the same procedure over and over again , this will keep the last 10Mb of actuial data that was sent over ALL the lan interfaces , it will not filter or distinguish , it is imperative you start the trace and make it run before the problem is there , then simulate it so the most recent file contains the packet sequence containing the problem


then stop the trace

nettl -tf -e all


you will then have 1 or 2 files

filename.TRC0
filename.TRC1

these are unreadable so we need to format them , we filter out0only traffic between the machine that was telnetting or telnetted to and this machine and look at the sequence so wqe can determine if and for what reason we stop sending data


procedure

create file
.


filter ip_saddr
filter ip_daddr
.


netfmt -N -c -l -f filename.TRC0 or .TRC1 > file

then the data will be 'readable' , it will berepresente d in packet format formatted and each data packet will be displayed 3 times , on mac , ip and tcp level , you can then follow it and find out the events

the command nettl and netfmt are explained in the man pages complete with examples


hope this helps

[Steve Steel]

Hi

You should amke sure you have latest arpa and telnet patches.

With dependencies at 11.00 looks like this list.
PHNE_24715 PHKL_21857 PHKL_18543
PHCO_13411 PHCO_17058 PHKL_17038
PHKL_20016 PHKL_22589 PHNE_22566
PHKL_24027 PHNE_26096 PHCO_21596 PHCO_24542

They all should be on the box

Steve Steel

[GregJ_1]

You might want to format the nettl log file to see if this clues you in on something:

cd /var/adm
/etc/netfmt -lNf nettl.LOG00 > /tmp/fmt0
vi /tmp/fmt0
(Shift-g to the bottom and work your way up.)

-Could be a possible duplicate ip address issue.

[Sandip Ghosh]

Start the inetd daemon in debugging mode or enable the logging for inetd. Then you will get a detail message from syslog.log. But be careful, your syslog file will be growing too fast.

#inetd -l for enable the logging
#inetd -b for enable debuging

Sandip

[Roger Walton]

Julio,
It may be some querky network problem, or it might not be network related at all.

I assume you're referring to Progress database. Check the Progress *.lg (log) files to see if Progress is closing the sessions. If the .profile for the users that are being logged off runs Progress and then exits, see if the same thing happens when telneted in as root or another user that stays at a command prompt. It may appear the telnet sessions are being terminated abnormally, but it may actually be the database or the application running on the database that is terminating the session.

Make sure there isn't a user license issue with the application, Progress or HP-UX.

Also check to make sure you have large enough values for kernel parameters *npty* and *nstrpty*.

I hope this helps.

Roger

[Julio Rodriguez_4]

I 've tried to ping and it works, but after 20 tries, it takes up to 190 ms to respond from another node in the same network!
wHAT I did lastly, is to change the interface network cable, I hope that could helps.

[harry d brown jr]

Julio,

Do you have a default gateway defined?

live free or die
harry

[Julio Rodriguez_4]

Not just the information that resflects the netstat -r Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 11879 lo0 4136
192.6.7.59 192.6.7.59 UH 0 7986 lan0 4136
192.6.7.0 192.6.7.59 U 2 0 lan0 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 413

[Steven Sim Kok Leong]

Hi,

Where is your default route? Can you verify your settings for ip_ire_gw_probe? Your printout in an earlier post appears to have missed a missing zero behind.

# ndd -set /dev/ip ip_ire_gw_probe 0

0 is needed to disable the probe.

Hope this helps. Regards.

Steven Sim Kok Leong

[Julio Rodriguez_4]

I missed to put in the message, but i've made it well
ndd -set /dev/ip ip_ire_gw_probe 0

[Steven Sim Kok Leong]

Hi,

You don't have a default router/gateway configured in your routing table. That means you only need to transfer data within your local LAN itself. Is that so?

I think we need more information on when the telnet connections get closed and the environment when they get closed.

Can you run a loop with the shell in a telnet session and check whether the telnet session still gets terminated:

# while sleep 10;do echo date;done

Did you set tcp_keepalive_interval to too small a value? (default is 2 hrs)

# ndd -get /dev/tcp tcp_keepalive_interval

Hope this helps. Regards.

Steven Sim Kok Leong

[Julio Rodriguez_4]

That's correct, it just work in the same network
The telnet sessions get closed, even if they are working in a shell

I'm going to try with the ndd keepalive