TCP ZeroWindow in telnet connections

[Jose M. del Rio]

We are having intermittent problems in a server: users can't telnet to the server.
By sniffing we can see the sequence (see attached capture.pcap):
- 3-way handshaking
- client sends first telnet packet
- server acks the packet immediately at the TCP level
- many seconds, even minutes, pass without the server sending another packet (first telnet response packet)
- the client eventually sends FIN to close the connection
- server acks the packet immediately at the TCP level
- some time later the server advertises TCP ZeroWindow, FIN ACK
- client rejects (RST) these packets
- server logs "Dec 20 18:04:22 alicante telnetd[4756]: getpid: peer died: Error 0" in syslog.log.

After reading many forum threads, I wonder if raising tcp_recv_hiwater_def could help.
Nevertheless, I have some existential questions:
1) How is it possible that the socket just opened by the new telnetd process can advertise TCP ZeroWindow if only a few bytes have been received?
2) What is the server doing during those minutes?

[Laurent Menase]

update xport patch, it is a very old bug fixed in a very old patch

[Jose M. del Rio]

Do you mean latest ARPA patch (PHNE_39386)?
We already have it.

[Laurent Menase]

indeed I didn't read precisely your question,
and I thought about zero window replied to syn.


looks like you have a firewall between the 2 systems.

windows is closed since peer as sent a fin

[Laurent Menase]

you should take a trace from the 2 side

[Jose M. del Rio]

It's a reverse DNS resolution issue: telnetd is trying to resolve IP -> name for IPs it doesn't know about and that process is taking longer than the telnet client is willing to wait for, so it closes the connection.