From owner-freebsd-hackers Tue Oct 7 23:58:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA26062 for hackers-outgoing; Tue, 7 Oct 1997 23:58:13 -0700 (PDT) (envelope-from owner-freebsd-hackers) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA26057 for ; Tue, 7 Oct 1997 23:58:08 -0700 (PDT) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.6.12/8.6.12-s1) with UUCP id IAA08075; Wed, 8 Oct 1997 08:57:37 +0200 Received: (from j@localhost) by uriah.heep.sax.de (8.8.7/8.8.5) id IAA13965; Wed, 8 Oct 1997 08:47:17 +0200 (MET DST) Message-ID: <19971008084717.VY20773@uriah.heep.sax.de> Date: Wed, 8 Oct 1997 08:47:17 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: hackers@FreeBSD.ORG Cc: jonny@coppe.ufrj.br (Joao Carlos Mendes Luis) Subject: Re: TCP problem References: <199710080122.XAA00461@gaia.coppe.ufrj.br> X-Mailer: Mutt 0.60_p2-3,5,8-9 Mime-Version: 1.0 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199710080122.XAA00461@gaia.coppe.ufrj.br>; from Joao Carlos Mendes Luis on Oct 7, 1997 23:22:56 -0200 Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I hope Bill Fenner will jump in with better guesses than mine... :) As Joao Carlos Mendes Luis wrote: > 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. > 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, 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. 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 another bug report yesterday where increasing some TCP parameter yielded an unusable connection. I think Bill has fixed something in this area yesterday. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)