From owner-freebsd-hackers Wed Oct 8 14:53:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA17118 for hackers-outgoing; Wed, 8 Oct 1997 14:53:43 -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 OAA17104 for ; Wed, 8 Oct 1997 14:53:36 -0700 (PDT) (envelope-from jonny@coppe.ufrj.br) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.7/8.8.7) id TAA24952; Wed, 8 Oct 1997 19:53:09 -0200 (EDT) From: Joao Carlos Mendes Luis Message-Id: <199710082153.TAA24952@gaia.coppe.ufrj.br> Subject: Re: TCP problem In-Reply-To: <19971008124102.17436@lemis.com> from Greg Lehey at "Oct 8, 97 12:41:02 pm" To: grog@lemis.com (Greg Lehey) Date: Wed, 8 Oct 1997 19:53:08 -0200 (EDT) Cc: jonny@coppe.ufrj.br, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk #define quoting(Greg Lehey) // > but there's a problem somewhere. The very strange thing is that's // > intermitent. Most of the time it works perfectly. // > // > Also curious, the chargen always stops at the same char. // // The 01? Yes. 160 chars received by telnet. But tcpdump shows 164 chars transfered, curiously... 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) // > I have no problem connecting from/to other machines to/from both of these. // // Is this just a problem with a single connection, or with all // communication between the two machines? Are there other machines on All kind of tcp communication. ssh, smtp, http, etc. // the net? If so, how do they communicate with these two machines? No problem at all, as far as I could see. To get into the linux machine ssh'ed to a Solaris one, and then ssh'd again from there. // > Rebooting the Linux machine does not solve the problem, but rebooting the // > FreeBSD one does solve, so I think it's a FreeBSD problem. Any suggestions ? // // The traces show that the machine with the trouble is IP 146.164.53.91. // The dumps on both sides show 146.164.53.91 retrying an ack, and // 146.164.53.200 responding to it immediately. To get the sequence // straight, look at the timestamps: // // > 22:47:22.885018 146.164.53.91.19 > 146.164.5.200.2038: . ack 1 win 31744 [tos 0x10] (ttl 64, id 13098) // > 22:47:22.885018 146.164.5.200.2038 > 146.164.53.91.19: . ack 165 win 0 (DF) [tos 0x10] (ttl 63, id 38673) // // Interesting. This is the Linux box, and it claims a response in 0 // µs. In fact, since the last 4 digits of the timestamp are always // 5018, I assume that it can't resolve more than .01 s. It's a misfeature, but not necessarily a bug. // Since the tcpdump on the Linux side shows the data going in, I can // only imagine it's a bug in the Linux TCP/IP stack. // // So why does it recover when you reboot the FreeBSD machine? Probably // a connection reset when the machine comes up. It should also recover Nope, since this happens to EVERY tcp connection. // if you reboot the Linux box, and possibly if you take the interface // down and up again. I did reboot linux first, as a Linux bug was my first thought. It did not solve. I think the 0-sized window problem is the one, as David pointed. Also, FreeBSD is sending these packets as "Don't Fragment", is this a "feature" ? 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