DTC 16TN sessions hanging if more than 2 DTC's active

[Grant Te Brugge]

We have a number of DTC16TN's. Whenever more than 3 are running concurrently the user sessions on the third DTC hang.

dtcresets or reconfiging the DTC does not help the situation

Any suggestions would be appreciated

thanks

Grant

[Brad Marks · Accepted solution]

Grant,
First, verify that each dtc has been assigned a unique ip address. Second verify that there are proper entries for each port of each dtc in /etc/ddfa/dp. Third make sure that you are using /dev/telnet as the directory name in the third /etc/ddfa/dp entry. You might want to use a non-default logging level on one or more ports of the hanging dtc, and view logging messages in syslog.log (see log_level in man page for dp).
Also, via dtcconfig, verify that keepalive is turned on for ports.
By the by, what rev of HP-UX are you using. This advice is from a 10.20 user and I'm not familiar with any 11 caveats.
Best of luck!

[Grant Te Brugge]

Brad

The only file in the /etc/ddfa directory is
preditpcf

Contents
telnet_mode: enable
timing_mark: enable
telnet_timer: 120
binary_mode: enable
open_tries: 1
open_timer: 15
#close_timer: 5
close_timer: 0
status_request: disable
status_timer: 30
eightbit: enable
tcp_nodelay: enable

Contents end

There is not a dp file. Our version is 10.20

thanks

Grant

[Grant Te Brugge]

Brad

Further to my last message. Keep Alive is enabled on all ports.

I have changed the log level and will check the syslog.

thanks

Grant

[Brad Marks]

Grant,
I really think that you need both a /dev/telnet directory (if you haven't one) and /etc/ddfa/dp. Please refer to the dp man page to better understand why this is needed (found in the "Telnet Port Identification" section). For example, here are the entries for dtc01 on my system (its ip address is 139.64.100.32). By the way we currently support 20 dtcs.

139.64.100.32 01/00 /dev/telnet/d0100
139.64.100.32 01/01 /dev/telnet/d0101
139.64.100.32 01/02 /dev/telnet/d0102
139.64.100.32 01/03 /dev/telnet/d0103
139.64.100.32 01/04 /dev/telnet/d0104
139.64.100.32 01/05 /dev/telnet/d0105
139.64.100.32 01/06 /dev/telnet/d0106
139.64.100.32 01/07 /dev/telnet/d0107
139.64.100.32 01/08 /dev/telnet/d0108
139.64.100.32 01/09 /dev/telnet/d0109
139.64.100.32 01/10 /dev/telnet/d0110
139.64.100.32 01/11 /dev/telnet/d0111
139.64.100.32 01/12 /dev/telnet/d0112
139.64.100.32 01/13 /dev/telnet/d0113
139.64.100.32 01/14 /dev/telnet/d0114
139.64.100.32 01/15 /dev/telnet/d0115

When a user logs on via a dtc port, the corresponding /dev/telnet/dnnnn entry will be created. You might want to start by creating entries in dp for the troublesome dtc to see if that garners better results.

[Brad Marks]

Oh yeah, it might also be interesting to see what entries there currently are in /dev/telnet...

[Grant Te Brugge]

Brad

Thanks for the speedy and detailed repsonses.

I think the difference is that we do not have unique names assigned to each port.

I also noticed in the syslog that there are Telnetd time out errors for the sessions on the DTC in question.

thanks

Grant