Hello, one gave me the advice to send this topic to this list instead linux-kernel. There seems to be a bug in net/ipv4/tcp_output.c - tcp_send_probe0(...): During a tcp write the receiver can hold the connection by respondig with ACKs window size 0. In this situation the sender (linux) has timeouts between sending ACKs to test, if the connection is still valid. This timeout is controlled by "min(tp->rto << tp->backoff, TCP_RTO_MAX)". tp->backoff is allways increased by 1. On a 32 bit machine at least a tp->backoff value of 32 results in a 0 for this expression. This causes a burst of ACKs wich cannot be responded by the receiver (It would be even worse, if the receiver ACKS them). I would suggest to increase the backoff value only, if (min(tp->rto << (tp->backoff+1), TCP_RTO_MAX) != TCP_RTO_MAX) BTW: the sitiuation is a network printer with paper empty. The connection breaks when backoff is 31 (tp->rto = 22). This is after ~45 minutes. bye, Martin > Actually the printer network interface ACKs all incoming packets > with window size zero > > Everything is fine until the standard TCP/IP implementation shifts > a "22" (tp->rto) 31 (tp->backoff) times to the left and sends 16 ACKS in > 0.5ms, because it does no timeouts between them. > > A "60 minute paper empty"-situation should not cause problems. > > I could provide a tcpdump trace of this, if wanted. ------------------------------------------------------- -- Martin Zielinski mz@seh.de - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
