Still that telnet latency

[Dietmar Konermann]

Hi, Ralph!

Oops... I'm sorry. You are right, this wrapped telnetd does not work. Looks like some security feature; you see the same if you use a wrapper without "exec"... then login fails even without tusc.

And running tusc on inetd could be really too verbose. :) Didn't you say the delay happens _before_ the login: prompt appears? Why not use the data if if the login fails?

BTW, maybe this works as non-root also... I didn't test it.

Best regards...
Dietmar.

[Dietmar Konermann]

Ralph,

I see you've just logged a case here in Ratingen. I will point the owning engineer to this thread. :)

Best regards...
Dietmar.

[Ralph Grothe]

Dietmar,

I've just talked to your colleague, and he seems to know the cause.

The inetd is running with the "-l" option and is serving a lot of clients from unknown origin where it cannot reversely resolve the FQN from their IPs.

So what we need is, because the customer requires inetd's session logging, some patch that supplies inetd with something like the "-n" switch for netstat, and that prevents it from trying reverse resolution.

[Jochen Heuer · Accepted solution]

Hi there,

I am the engineer who got the call from Mr. Rothe. To me the problem seems to be inetd hanging while trying to do the reverse lookup of the incoming ip address (inetd -l -> every connection is logged with the resolved name). Since inetd is single threaded local connections (whose name does resolve quickly) can be delayed too.

The fix is to install a current inetd patch (>= PHNE_28312) and use the '-s' option too. Then the connection is still logged but only with ip address.

Best regards,

Jochen

[Jochen Heuer]

Hi Ralph,

I did not see your post but that sums it up exactly :)

Best regards,

Jochen

[Ralph Grothe]

Since the patches README, especially this section


2. JAGad01042 /SR 8606131892
inetd -l causes inbound connection delay if the hostname
lookup required for logging is slow.

Resolution:
A new option "-s" is provided to suppress the hostname in
the connection log message.


sound very promissing to me, I'm pretty faithful that this damned patch will solve our problem.
Btw, it's interesting to note that the README bears this header as the date of posting/release of the patch


# grep -i post\ date PHNE_28312.text
Post Date: 03/04/30


So probably no wonder no one was able to help me when I first submitted a support call to HPs' in this matter.
I'm almost tempted to suspect that I'm one of the many customers that finally made HP come up with this patch (possably the drop that spilled the barrel, as a German saying goes ;-)

But checking the patch's list of prerequisite fellow patches (the beloved PHKL rebooters) I had to conclude that we still lack a few.
This calls for another downtime.

As soon as I get the customers' placet I will be popping back into this thread to assign Jochen his deserved rabbits.

[Ralph Grothe]

Jochen,

this morning I checked again the logfile of my telnet checking daemon.
The longest latency has been 3.75 secs since its restart after bringing inetd in hostname-ignore-mode through SIGPIPE.

I'm now pretty confident that I can cease the checks.

Many, many thanks for supplying the patch :-)