This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 19 21:44:26 2024 Received: from entropy.muc.muohio.edu (entropy.muc.muohio.edu [134.53.213.10]) by herbie.ucs.indiana.edu (8.8.8/8.8.8) with ESMTP id RAA19072 for ; Sun, 16 Aug 1998 17:48:46 -0500 (EST) Received: from vger.rutgers.edu (root@vger.rutgers.edu [128.6.190.2]) by entropy.muc.muohio.edu (8.8.7/8.8.7) with ESMTP id SAA26684; Sun, 16 Aug 1998 18:41:13 -0400 Received: by vger.rutgers.edu id <154116-22291>; Sun, 16 Aug 1998 17:22:22 -0400 Received: from mailout04.btx.dtag.de ([194.25.2.152]:6339 "HELO mailout04.btx.dtag.de" ident: "NO-IDENT-SERVICE[2]") by vger.rutgers.edu with SMTP id <154558-22291>; Sun, 16 Aug 1998 17:16:58 -0400 Received: from fwd12.btx.dtag.de (fwd12.btx.dtag.de [194.25.2.172]) by mailout04.btx.dtag.de with smtp id 0z8B7l-0005dw-00; Mon, 17 Aug 1998 00:18:05 +0200 Received: from t-online.de (320017144399-0001(btxid)@[193.159.13.230]) by fwd12.btx.dtag.de with smtp id ; Mon, 17 Aug 1998 00:17:54 +0200 Message-Id: <35D75A35.FA20C96A@t-online.de> Date: Mon, 17 Aug 1998 00:16:21 +0200 X-Mailer: Mozilla 4.5b1 [en] (X11; I; Linux 2.1.115 i686) X-Accept-Language: en Mime-Version: 1.0 To: linux-kernel@vger.rutgers.edu Subject: TCP stalls in 2.1.1xx kernels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Sender: 320017144399-0001@t-online.de From: Markus.Schoder@t-online.de (Markus Schoder) X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu Sender: owner-linux-kernel@vger.rutgers.edu Precedence: bulk X-Loop: majordomo@vger.rutgers.edu Some people see TCP stalls with recent kernels. Me too. After I disabled TCP time stamps (by doing an echo 0>/proc/sys/net/ipv4/tcp_timestamps) everything worked fine. With TCP time stamps enabled I got lots of IpInHdrErrors (checked with cat /proc/net/snmp) and tcpdump logged an equal number of incoming packets with "truncated-ip - 9 bytes missing". Those packets where then ignored by the kernel (no ack send) and caused long stalls while waiting for retransmission. I can't really see how this all fits together because if there is an IpInHdrError the packet is immediately discarded and the TCP layer shouldn't even see it. Right? So why can a TCP option make a difference? Perhaps somebody more knowledgeable about (Linux-)networking can shed some light on this. All this was with a stock 2.1.115 kernel over an ISDN syncPPP connection. -- Markus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html