problem with telnet. Please help !

[Tan Shirley]

Hi,

I have a HP L-class box and users feedback that it takes a long time for them to get the login prompt wheen they try to connect to the L-class server using normal telnet. I tried it myself and indeed it's taking something like more than a minute or so to see the login prompt comes out. Why is that so?
Or is there any parameter to specify how long to wait before we get the login prompt ?

Really appreciate any advise.

Regards,
Shirley

[Vincenzo Restuccia]

It might also be worth trying "telnet localhost" to see if your telnet server is working properly.If it is ok the problem is with the network.

[Rainer von Bongartz]

did you set up quotas ???

then it might take quit a long time to login , especially if
you have an NFS mount which is down or some other
problems with mounted devices

[eran maor]

Hi

In addition to a number of defect fixes, the latest telnetd(1M) General Release
patch PHNE_22159 contains a performance enhancement and an updated man page.

The performance enhancement is derived from the fix in JAGab16743 and allows
telnetd to be tuned for optimum performance for applications generating small,
often single byte writes to a telnet client, but also requiring fast interactive
response from the terminal keyboard.

Prior to PHNE_22159 a non-documented option -TCP_DELAY provided a degree of
tuning to allow some concatenation of outbound data from telnetd to the telnet
client. In most cases, adding -TCP_DELAY to the telnetd command line in
/etc/inetd.conf is sufficient to achieve the same telnetd performance over
11.0 as was seen by a telnet application on HP-UX 9.X or 10.X

However in some cases using -TCP_DELAY reduces to an unacceptable level the
interactive response times on keyboard intensive applications.
In this case using the new telnetd options instead of -TCP_DELAY should provide
the optimum of good throughput and acceptable interactive response from the
keyboard.

The new options are -s buffersize and -z buffer timeout. Both these new options
and the existing -TCP_DELAY option are now documented in the telnetd(1M) man
page provided with PHNE_22159.

-TCP_DELAY
This option allows users to disable the TCP_NODELAY socket option. When telnetd
is invoked with this option, small writes over telnetd may concatenate at the
tcp level so that larger tcp packets are sent to the telnet client at less
frequent intervals.

-s
This option allows users to set the BUFFERSIZE value. When set, this informs
telnetd of the number of user bytes to concatenate before
sending to TCP. This option is set with integer values. There is no specified
default.

-z
This option allows users to set the BUFFERTIMEOUT value. When set, this informs
telnetd how long it should wait before timing out and flushing
the concatenated user data to TCP. Note that the TIMEOUT value is measured in
clock ticks (10ms) and not in seconds. This option is set with integer values.
There is no specified default.


For example, to configure telnetd to use the -TCP_DELAY option - which should
be effective for most cases where telnet tuning is required, the entry in
/etc/inetd.conf would be

telnet stream tcp nowait root /usr/lbin/telnetd telnetd -TCP_DELAY

To configure telnetd to have a BUFFERSIZE of 100 bytes and a BUFFERTIMEOUT of
100 ticks (1 second) the entry in /etc/inetd.conf would be:

telnet stream tcp nowait root /usr/lbin/telnetd telnetd -s100 -z100

Remember to add the minus sign to each option and insert no spaces between the
minus sign and the option value. Stop and start inetd after each change to
/etc/inetd.conf. Also note a tuning change only applies to a new inbound telnet
connection, not existing telnet connections.

[Tracey]

I was having a similar problem at one time when I had turned NIS on for awhile and then turned it off. When it was turned off, there were still some conifguration files that were looking for an NIS server and would keep trying until they timed out - then and only then would I get a login prompt.

[Rita C Workman · Accepted solution]

When a user telnets into your box...it has to resolve who the person attempt to login ...is...
Depending on how your system is set up...it will go and try to resolve who they are based on how your /etc/nsswitch.conf is set up (hosts,DNS,NIS...). So if the user is not identified on your hosts file it will check DNS and that is where it will hang for about 100seconds. When it finally gives up, it will return the login prompt.

The way around this is to setup those telnet folks either under your /etc/hosts file or via DNA in the named.boot.

There is an HP document on this: A5338041
http://us-support.external.hp.com/cki/bin/doc.pl/sid=917eb0d1187a7c6208/screen=ckiDisplayDocument?docId=200000027709160

If you don't have access to the document I can post it, but basically it says what I just mentioned.

Hope this helps,
Rita

[Tan Shirley]

Hi all,

Thanks for all the advise !
I realised that my /etc/nsswitch.conf is using dns instead of files, hence the long interval before I get my login prompt !

Thanks a miilion ! You guys are of great help !

Regards,
Shirley