From owner-freebsd-hackers Wed Oct 8 14:35:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA16061 for hackers-outgoing; Wed, 8 Oct 1997 14:35:22 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from gaia.coppe.ufrj.br (jonny@cisigw.coppe.ufrj.br [146.164.5.200]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA16047 for ; Wed, 8 Oct 1997 14:35:17 -0700 (PDT) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id TAA24677; Wed, 8 Oct 1997 19:34:43 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199710082134.TAA24677@gaia.coppe.ufrj.br> Subject: Re: TCP problem In-Reply-To: <19971008084717.VY20773@uriah.heep.sax.de> from J Wunsch at "Oct 8, 97 08:47:17 am" To: joerg_wunsch@uriah.heep.sax.de Date: Wed, 8 Oct 1997 19:34:43 -0200 (EDT) Cc: hackers@FreeBSD.ORG, jonny@coppe.ufrj.br X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(J Wunsch) // > 22:49:35.574865 146.164.5.200.2038 > 146.164.53.91.19: S 1153321686:1153321686(0) win 65535 (DF) [tos 0x10] (ttl 64, id 38631) // // Btw., you should run tcpdump with a larger snaplen (-s 200 for // example). The "|tcp" above means you don't see the complete packet // options displayed. Probably not very important here, though. This happens with any kind of TCP connection. I used chargen just for demonstration purposes. // > 22:49:35.576498 146.164.53.91.19 > 146.164.5.200.2038: S 2381730138:2381730138(0) ack 1153321687 win 31744 (ttl 63, id 13086) // > 22:49:35.576825 146.164.5.200.2038 > 146.164.53.91.19: . ack 1 win 164 (DF) [tos 0x10] (ttl 64, id 38632) // // What looks interesting to me is that, while the SYN packet offered a // window of 64 K, the first data packet only offers 164 bytes. And: // // > 22:49:35.614489 146.164.53.91.19 > 146.164.5.200.2038: P 1:75(74) ack 1 win 31744 (DF) [tos 0x10] (ttl 63, id 13088) // > 22:49:35.804015 146.164.5.200.2038 > 146.164.53.91.19: . ack 75 win 90 (DF) [tos 0x10] (ttl 64, id 38638) // > 22:49:36.646712 146.164.53.91.19 > 146.164.5.200.2038: P 75:165(90) ack 1 win 31744 [tos 0x10] (ttl 63, id 13091) // > 22:49:36.804033 146.164.5.200.2038 > 146.164.53.91.19: . ack 165 win 0 (DF) [tos 0x10] (ttl 64, id 38646) // // ...none of these bytes are claimed to be delivered to the application, ???? The application in case was telnet, and it has received the data. // so the window goes 0 for some reason. You see it stopping always at the // same point since it's probably always offering exactly the same 164 bytes // in the first data packet. // // You might get some hints out of `netstat -s', perhaps. Looking for mbuf leakage as David suggested or nothing in particular ? // What makes me wonder is why it's offering a 64 KB window in the first // SYN at all? If i try it here, it only offers 16 KB. Did you // manipulate the TCP-related kernel variables? I remember there was Uh, er, yes... :) I wanted to test some parameters in order to push network performance since this machine is a mid-sized squid server that I'm using to project bigger ones. /usr/sbin/sysctl -w kern.somaxconn=1024 /usr/sbin/sysctl -w kern.maxsockbuf=1048576 /usr/sbin/sysctl -w net.inet.tcp.sendspace=65536 /usr/sbin/sysctl -w net.inet.tcp.recvspace=65536 /usr/sbin/sysctl -w net.inet.tcp.always_keepalive=1 But the problem in question does not always happen. And when it happens, it only happens with the Linux machine. It continues working perfectly with other machines. // another bug report yesterday where increasing some TCP parameter // yielded an unusable connection. I think Bill has fixed something in // this area yesterday. Has this been integrated to RELENG_2_2 ? Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 jonny@coppe.ufrj.br Universidade Federal do Rio de Janeiro UFRJ/COPPE/CISI PGP fingerprint: 29 C0 50 B9 B6 3E 58 F2 83 5F E3 26 BF 0F EA 67