Date: Wed, 8 Oct 1997 19:53:08 -0200 (EDT) From: Joao Carlos Mendes Luis <jonny@coppe.ufrj.br> To: grog@lemis.com (Greg Lehey) Cc: jonny@coppe.ufrj.br, hackers@FreeBSD.ORG Subject: Re: TCP problem Message-ID: <199710082153.TAA24952@gaia.coppe.ufrj.br> In-Reply-To: <19971008124102.17436@lemis.com> from Greg Lehey at "Oct 8, 97 12:41:02 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
#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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710082153.TAA24952>